Hi Young,
Thanks a lot for your answers. Please see some more comments inline.
Again with now the ALTO list in Cc
Best regards
Sabine
Leeyoung a écrit :
Hi Sabine,
Here's my response to your comments to your detail questions. Please see
in-line.
Sreekants or Greg may be able to provide more comments later.
Thanks,
Young
-----Original Message-----
From: Sabine Randriamasy [mailto:[email protected]]
Sent: Monday, July 30, 2012 12:14 PM
To: Leeyoung
Cc: [email protected]
Subject: Re: [altoext] FW: New Version Notification for
draft-lee-alto-app-net-info-exchange-00.txt
Hi Young,
I have read your draft and have a couple of comments and questions.
In Section 2 Problem statement, I agree with the need to reduce the
amount of conveyed ALTO information through topology filtering and
constraint-based response filtering. The ALTO base protocol specifies
these features for the Cost Map, Filtered cost map and Endpoint cost
services. I also agree with the necessity to provide several types of
cost information which stresses the necessity of extended filtering
mechanisms. In the Constraints filtering extensions of Section 3, I
didnt' really get how information confidentiality is preserved and the
proposed specification raised the questions detailed below.
I also agree that detailing end to end path costs at the link level at
some places can be beneficial, especially for local bottlenecks
sometimes with fast changing cost values. Figure 2 shows an example with
Link capacity costs but section 2 uses them rather as capacity, where I
figure the higher the better. Without a hint on how path costs are
calculated it is hard to follow the rationale on the DC choice by ER1.
See also the questions detailed below.
Thanks,
Sabine
------------------------- Detailed questions -----------------------------
++ Section 3.1 ALTO Query from Application Stratum to Network Stratum
Names used in the list of requested information may be misleading:
- A 'Cost Type' see base protocol (§5.1.1) is expected to indicate an
attribute that has a value such as number, boolean, string... and is is
rather "semantic". 'summary' and 'graph' are cost attributes of
different nature.
YOUNG>> Thanks. Agreed. We may define a new cost attribute (TBD the name).
- 'Constraints' such as 'min/max metric' look like objectives rather
than expressions such as 'lt. value' as specified in the base protocol
(§ 6.8.2.2.3)
YOUNG>> In the encoding example we gave in the draft, we used the constraints
Convention such as 'lt, gt, eq, ...' Please see Section 3.5.
Ok. Then it may help if the text in §3.1 is reflecting such an
expression of constraints.
- what kind of information is member 'Parameters' is supposed to carry
and for what use?
YOUNG>> We put it as a place holder for indicating values of the resulting
graph or link
representation of network abstraction, but in the actually encoding example, we
simply used
what is defined in DstCostsConstraints Object (such as pktloss, etc.) to
indicate the vaules
associated with the S-D path. We can delete it if this is not necessary.
Or maybe clarify the definition.
- Some members listed here do not appear in the ALTO Query Information
Model of §3.3: 'parameters' 'objective-function'. Neither do they appear
in the example of §3.5
YOUNG>> Good observation. We put them as a place holder for future enhancement.
++ Section 3.2 ALTO response from Network ....
- The list of S-D pairs should carry the Cost Type *values* as the
supported Cost Types are expected to be listed and checked in the IRD.
YOUNG>> We did not mean not leaving it out. See Section 3.5 example if that satisfies your question.
Ok, then adding the *value* to "cost type" would fully clarify
- 'Constraint values': need to be clarified: is it the actual cost
value? then the draft should specifiy that the constraits relate to Cost
Types (as defined in §5.1.1).
YOUNG>> Yes. Agree.
- how is the 'Administration Domain ID' of a S-D pair reported and why
is it needed?
YOUNG>> Sorry for poor writing. We didn't mean this Admin Domain ID of a S-D pair. We actually meant here ALTO client may collect network resource information from different network domains in case of the multi-domain scenario.
ok
++ Section 3.3 Information Model of ALTO Query ...
Looking at the specification here, it is hard to figure out what is
really extended here w.r.t. the Endpoint Cost Service query input
specified in the base protocol.
YOUNG>> Agreed. We will indicate what is new in the revision.
- A new media type "CsoReqEndpointCostMap" and differs from
"ReqEndpointCostMap" of the base protocol in that the set in member
'contraints' is encoded/interpreted differently, according to example in
§3.5. Then a different member name than 'contraints' should be used.
YOUNG>> Yes, we will make it clear.
Ok
- As for member 'endpoints': unless you need to specify only 1 src EP,
what is the need to define a new object "EndpointFilterExt" instead of
keeping the "EndpointFilter"?
YOUNG>> We may have a case in which to specify more than 1 src EP. The example is
Simply an example with only 1 src EP. We have other examples where multiple sources may need to be specified.
Ok. Then why not keeping "EndpointFilter"?
++ Section 3.4 Information Model of ALTO Response ...
- object CsoInfoResourceEndpointCostMap has the same structure than
InfoResourceEndpointCostMap of base protocol
YOUNG>> Yes, we did not mean to invent new object.
Ok. I guess a later version with updated information models and examples
will clarify this as well.
- what in the list of §3.2 does object 'DstCostsConstraints' refer to?
- this object seem to be encoded like a set of JSONNumbers that are the
values of resp. hopcount, latency and packet loss. So I guess, they
should be arranged in an array.
YOUNG>> Actually it refers to constraint values. I tend to agree with you.
- why is this set of cost types already set at this level of
specification?
YOUNG>> I don't understand this question.
I meant the list of cost types used in the constraints could be more
generic.
++ Section 3.5 ALTO protocol extension...
I agree with the idea of providing several Cost Type values at a time
but the encoding could be lighter. The draft "Multi-Cost ALTO" proposes
one example.
There is a real need that this section be harmonized with the previous
specification sections, as the encoding provided in the examples are
misleading.
YOUNG>> Yes, we should have referred to your multi-cost draft properly. We did not mean to propose a new thing with respect to multi-cost. We will clean up what is new and what is referenced in the revision.
Ok.
++ Section 4.1 Representing....
- this section is rather about representing links and their attributes,
so could be named accordingly
YOUNG>> We discussed this aspect previously. Do you have a good suggestion of
Naming?
How about something like "Representing links and their attributes" ?
- the graph specification is curretnly a list of links, do you intend to
extend so that one can infer its structure?
YOUNG>> Please look at draft-bernstein-alto-large-bandwidth-cases-02.txt for
Further enhancement from this. We want to represent some path vector only with
shared links and the link cost of those shared links so that some level of
structure may be inferred by Application stratum.
Ok.
- is there a reason preventing member 'r-cap' to be specified as
JSONNumber capacity?
YOUNG>> I think we can. But I defer this question to Greg.
- what is the usage of wt at this level of a spec ? (could also be
'JSONNumber weight')
YOUNG>> Weight is similar to routing 'cost' notion of OSPF or other link cost that operators use for non-TE link cost.
I was mislead by the name 'wt' (sorry forgot the expression in the other
draft).
Leeyoung a écrit :
Hi All,
We have just published ALTO extension to support application and network
resource information exchange for high bandwidth applications.
This is part of the i2aex initiative.
Thanks in advance for your comment and discussion.
Young
-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Monday, July 09, 2012 11:06 AM
To: Leeyoung
Cc: [email protected]; Sreekanth madhavan; [email protected]; Dhruv
Dhody
Subject: New Version Notification for
draft-lee-alto-app-net-info-exchange-00.txt
A new version of I-D, draft-lee-alto-app-net-info-exchange-00.txt
has been successfully submitted by Young Lee and posted to the
IETF repository.
Filename: draft-lee-alto-app-net-info-exchange
Revision: 00
Title: ALTO Extensions to Support Application and Network Resource
Information Exchange for High Bandwidth Applications
Creation date: 2012-07-09
WG ID: Individual Submission
Number of pages: 14
URL:
http://www.ietf.org/internet-drafts/draft-lee-alto-app-net-info-exchange-00.txt
Status:
http://datatracker.ietf.org/doc/draft-lee-alto-app-net-info-exchange
Htmlized:
http://tools.ietf.org/html/draft-lee-alto-app-net-info-exchange-00
Abstract:
This draft proposes ALTO information model and protocol extensions to
support application and network resource information exchange for high
bandwidth applications in partially controlled and controlled
environments as part of the infrastructure to application information
exposure (i2aex) initiative.
The IETF Secretariat
_______________________________________________
altoext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/altoext
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
