Re: [alto] Chair review of unified-props (Part 2 of 2)

[Randriamasy, Sabine (Nokia - FR/Paris-Saclay)]

Hello Vijay,

Thank you for your review of Entity Property Maps. As promised, please find 
inline the answers from Jensen and myself on how your comments have been 
addressed, prefixed respectively by “[jensen]” and “(sabine)”.
Responses on sections 9.3 and 11, with “*”, request further feedback from 
you.
Thanks,
Sabine


From: Vijay Gurbani 
Sent: Wednesday, January 27, 2021 5:28 PM
To: draft-ietf-alto-unified-props-...@ietf.org
Cc: IETF ALTO 
Subject: Chair review of unified-props (Part 2 of 2)

Chair review from Section 5 - end (inclusive).

Please go through the Major review points, they require some attention.

This concludes my review of this document.  Overall a well-written document
covering a range of important extensions to ALTO.

Major:

- S5.1.1: "The '.' separator MUST NOT be used unless specifically indicated in a
further extension document." ==> I don't understand this.  If the '.' must not
be used, then this should be an absolute condition (MUST NOT is the normative
strength in the sentence).  If this document allows the '.' to be used in a
further extension document, then this is a relative --- not absolute ---
condition, and thus a normative SHOULD NOT seem to be better.  However, as
currently written, this sentence seems rather wishy-washy.  Either say '.' is
out of bounds or say it is not, it seems weird to say that this document does
not use it, but others can.

One way to achieve this is to replace that sentence with:

  The '.' separator is not used by this document, however, future
  extensions may use it.  For the purpose of this document, the
  strings "ipv4", "ipv6", and "pid" are valid entity domain
  types, while "ipv4.anycast", and "pid.local" are invalid.

However, even then, I am not sure if the above is correct.  Later, in S5.1.2,
you go on to say that "Note that the '.' separator is not allowed in
EntityDomainType and hence there is no ambiguity on whether an entity domain
name refers to a resource-agnostic entity domain or a resource-specific entity
domain."  Thus it seems to me that future extensions could run into trouble if
they allow '.' in the EntityDomainType.

This needs to be resolved before publication.
[ [SR] ] [Jensen] Thanks for noticing this bug. The '.' separator is not 
allowed even in an extension document.
The paragraph has been revised to the following:

   An entity domain has a type, which is uniquely identified by a string
   that MUST be no more than 64 characters, and MUST NOT contain
   characters other than US-ASCII alphanumeric characters
   (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the hyphen ('-',
   U+002D), or the low line ('_', U+005F).


- S5.1.2, last paragraph: "Note that the resource ID format defined in Section
10.1 of [RFC7285]..." ==> Section 10.1 of RFC 7285 defines "PID Name", not
"Resource ID", which is defined in the next section.  Please clarify.
[ [SR] ] [Jensen] New paragraph rephrasing now:
   Note also that Section 10.1 of [RFC7285] specifies the format of the PID 
Name which is
   the format of the resource ID including the following specification: ...


- S9.1: "...it is RECOMMENDED that the EPS be deprecated in favour of ..." ==>
This is very important: If this draft is recommending a change in RFC 7285, then
the status of this draft must say "Updates: 7285" at the top of the draft (it
currently does not).  This will cause the RFC Editor to enter a "Updated by:
RFC" in the masthead of RFC7285.

Further, I presume that since this update is a recommendation, the processing
rules of property map and filtered property map are distinct enough that legacy
ALTO servers and clients will continue operations?  Please advise.
[ [SR] ] [Jensen]  We do not intend to update RFC7285 to deprecate EPS.
This recommendation is more like suggesting that the new ALTO servers that 
support UP
should also provide the EPS to be backwards compatible with legacy clients.
Since the keyword "RECOMMENDED" has a specific meaning, let's not use this 
keyword here.
The paragraph has been changed as follows:
NEW
Since the Property Map and the Filtered Property Map defined in this
   document provide a functionality that covers the Endpoint Property
   Service (EPS) defined in Section 11.4 of [RFC7285], ALTO servers may
   prefer to provide Property Map and Filtered Property Map in place of
   EPS.  However, for the legacy endpoint properties, it is recommended
   that ALTO servers also provide EPS so that legacy clients can still
   be supported.


- S9.3: What does "little or no impact on other previously defined properties"
mean?  Again, this appears wishy-washy for a standards document.  Either we know
that there is some impact, and we document what the impact is, or we state that
there is no impact.  But saying "little or no impact" is not helpful.  Please
state where there is impact and whether this impact will cause backwards
compatibility problems.

I note that S12.2.1 further expands on this "little or no impact".  Perhaps a
seco

Re: [alto] Chair review of unified-props (Part 1 of 2)

[Randriamasy, Sabine (Nokia - FR/Paris-Saclay)]

Hello Vijay,

Thank you for your review of Entity Property Maps. As promised, please find 
inline the answers from Jensen and myself on how your comments have been 
addressed, prefixed respectively by “[jensen]” and “(sabine)”.
Responses on sections 4.7.1 and 4.4.3, with “*” request further feedback 
from you.
Thanks,
Sabine

From: Vijay Gurbani 
Sent: Tuesday, January 26, 2021 5:06 PM
To: draft-ietf-alto-unified-props-...@ietf.org
Cc: IETF ALTO 
Subject: Chair review of unified-props (Part 1 of 2)

All: My apologies for the late start on the chair reviews of the documents I am 
shepherding.  However, I have started the review.

Below is the first (of two parts) review of unified-props.  This review 
includes all sections from Abstract to Section 4.7.1 (inclusive).

Please let me know if you have any questions.  I will post the second part 
tomorrow.

Chair review from Abstract - Section 4.7.1 (inclusive).

Major:

- Abstract: "...by generalizing the concept of "endpoint properties" to generic
type of entities..." ==> Note that the antecedent ("endpoint properties") and
the consequent ("type of entities") do not match.  Perhaps better to say: "...by
generalizing the concept of "endpoint properties" as applied to endpoints
defined by IP addresses to endpoints a wider set of objects..."

More concretely:

OLD:
This document extends the base Application-Layer Traffic Optimization
(ALTO) Protocol by generalizing the concept of "endpoint properties"
to generic types of entities, and by presenting those properties as
maps, similar to the network and cost maps in the base ALTO protocol.

NEW:
This document extends the base Application-Layer Traffic Optimization
(ALTO) Protocol by generalizing the concept of "endpoint properties"
as applied to endpoints as defined by IP addresses to endpoints defined
by a wider set of objects.  Further, these properties are presented
as maps, similar to the network and cost maps in the base ALTO protocol.
[ [SR] ] [Jensen] It looks good to me. Done.


- S3.2.1: "An entity domain type is expected to be registered at the IANA" ==>
you mean "MUST be registered with IANA"?  Or "SHOULD be registered with IANA"?
Best to use normative language here, unless you have a specific reason not
to.
[ [SR] ] [Jensne] We changed "is expected to" to "MUST". Thanks for pointing it 
out.
I don't see any reason not to do it.

- S3.2.2: What does this mean: "As a consequence, entities in such
domains may be defined in a resource handling this domain type but
not in other resources handling this same domain type."?  I am unable to
parse this, I think you are saying that of all the resources handling a
particular domain type, the entity must be defined in only one of them.  If
so, perhaps best to reword; something like:
   OLD:
   As a consequence, entities in such domains may be defined in a
   resource handling this domain type but not in other resources handling
   this same domain type.
   NEW:
   As a consequence, of all the resources defining a particular domain
   type, the entity must be defined in only one resource.
[ [SR] ] (Sabine)
the point is rather to say that a domain can contain entities defined 
relatively to an information resource. In this case, the domain needs to have a 
name that ensures that the entities of the domain can all be retrieved and that 
with no ambiguities.
For instance: we may have 2 domains, "netmap1.pid" = {"mypidP", "mypidB", 
"mypidS"} and  "netmap2.pid" = {"mypidP", "mypidB", "mypidL"} . "mypidP" may or 
may not point to the same addresses in "netmap1" and "netmap2". This is not 
problematic as long as, when the Client queries "mypidP" defined in "netmap1" 
or "netmap2", it gets what is defined in these network maps for "mypidP".
The text has been rephrased in this direction. Please let us know if it is 
clear enough.

- S4.2.2, first paragraph: Is this example valid?  From my experience, ASN's
contain IPv4 addresses defined by a CIDR block.  I think it is highly unlikely
that a service provider will define a CIDR block 
(192.0.1.0/24) and have that
block span ASNs, but perhaps I am mistaken.  Perhaps someone from network
operations may want to look at this example and bless it, or if you are sure
that networks are architected in such a manner, then we can let it stay.
[ [SR] ] (Sabine)
Agree. Property "ASN" has been replaced with dummy property value "P".


- S4.6.2: "When an ANE has a persistent identifier, say, "entity-4", the
latter", here what do you mean by "latter"?  In this sentence, I do not see two
things that can be characterized as "former" and "latter"...?
[ [SR] ] [Jensen] New sentence: "An ANE may have a persistent identifier, say, 
"entity-4",
that is provided by the Server as a value of the "persistent-entity-id" 
property of this ANE."
(sabine)
the following sentence was also clarified as follows:
OLD
Further properties may be queried on an ANE with a persistent entity ID.
NEW
Further properties may then be queried on an 

Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy attributes(Internet mail)

[Randriamasy, Sabine (Nokia - FR/Paris-Saclay)]

Hello Chunchan,

Thanks for the clarification. If I understand well:
- the cloud gaming server (CGS) needs notifications on QoS CHANGE information. 
This change would be conveyed by an ALTO Server that abstracts NEF information 
to the ALTO Client in the CGS.
- only QoS CHANGES upon e.g. exceeding some hysteresis threshold are useful 
because Continuous QoS information is needless and causes signaling overhead. 
These changes should be reported to the CGS immediately. To this end, ALTO 
extended pub/sub is needed.
- regarding the pace of the notification, I would have a question: Your e-mail 
says “the cloud gaming server does need the real-time QUICK QOS CHANGE 
information” and later specifies “Quick QoS Change notification should not be 
too frequent, the QUICK QoS change notification should be minutes level”.
So what frequency does the term “real-time” in the 1rst sentence cover? Maybe I 
missed something. Definitely minute-level notification is achievable, given the 
limited size of the topology covered by ALTO in this case.

Another question:
- the number of possible QoS values Qi are quite limited and this “volatile” 
and light information would be conveyed with a given channel, say the channel 
“Ve” mentioned earlier by Richard.
- The longer term costs and properties reflecting QoS impacting KPIs such as 
latency L and throughput T would then be conveyed via ALTO channel “Vs” in an 
asynchronous way
-  would the values of these costs and properties be made dependent on the 
values of Qi?

Thanks,
Sabine



From: chunshxiong(熊春山) 
Sent: Friday, March 12, 2021 7:38 AM
To: Y. Richard Yang ; Randriamasy, Sabine (Nokia - 
FR/Paris-Saclay) 
Cc: alto-cha...@ietf.org; alto-...@ietf.org; Qin Wu ; IETF 
ALTO 
Subject: RE: [alto] ALTO Draft ReCharter WG review - extensible set of policy 
attributes(Internet mail)

Hello all,

@Randriamasy, Sabine (Nokia - 
FR/Paris-Saclay),  You say “An 
ALTO Server cannot provide real-time information".
I almost agree with your point.

But I want the ALTO Server to support very quick notification information to 
the ALTO Client, if there is a quick change as provided in my other email.

I think one goal of ALTO Server is not to  provide very frequent notification 
to the ALTO Client, but If there is some quick or big change, the ALTO Server 
needs very quickly notify the ALTO Client, just this, not repeated and 
continuous notify. I think this quick notification is very helpful for the 
cloud gaming server to adaptive change the coding scheme. But the cloud gaming 
does not need the ALTO server to repeated notify the current network bitrates. 
Cloud gaming server needs the change information not the status information. 
For the cloud gaming sever can “intelligently” detect the slow change 
information, but it is very hard for the gaming server to detect the quick 
change in short time (because there is buffer in the client and Server), in 
such case, if the ALTO server can provide such quick (QoS) change information 
to the cloud gaming server, the cloud gaming server can quickly change its 
coding scheme.

So, Yes, the cloud gaming server does NOT need the real-time QoS information, 
but the cloud gaming server does need the real-time QUICK QOS CHANGE 
information.

But, this Quick QoS change (e.g. Alternative QoS profile) is defined to trigger 
the cloud server to make some changes(e.g. encoding scheme change).  It should 
be avoid to define a  QUICK QOS change that does not trigger the cloud server 
to make any changes. So the real-time frequently reporting the current QOS to 
the cloud server is really not needed,  this repeated and continuous 
reporting/notification only creates a lot of message loads and no help for the 
cloud gaming server.

Also this Quick QoS Change notification should not be too frequent, the QUICK 
QoS change notification should be minutes level, i.e. one notification per one 
minute. In some cases, it is possible that the notification can be several 
notifications per one minutes, but the average rate should be less than one 
notification per one minute.


BRs,
Chunshan Xiong

From: alto mailto:alto-boun...@ietf.org>> On Behalf Of 
Y. Richard Yang
Sent: Friday, March 12, 2021 5:29 AM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>
Cc: alto-cha...@ietf.org; 
alto-...@ietf.org; Qin Wu 
mailto:bill...@huawei.com>>; IETF ALTO 
mailto:alto@ietf.org>>
Subject: Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy 
attributes(Internet mail)

Hi Sabine, Qin,

Good discussions.

I support the use cases of the design direction. One suggestion is to look at 
the design in a slightly abstract, general framework. In particular, the 
abstract framework looks like this to me:

- Ve: A set of "volatile" (ephemeral) variables; Ve tends to be small, 
fast-changing data;
- Vs: Another set of records 

Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy attributes

[Randriamasy, Sabine (Nokia - FR/Paris-Saclay)]

Hi Richard,

Thanks for your thoughts. This is definitely the path we want to take together 
with a flexible design to encode and represent information carried by Ve.
Meet you virtually at the ALTO session
Cheers,
Sabine

From: Y. Richard Yang 
Sent: Thursday, March 11, 2021 10:29 PM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 

Cc: Qin Wu ; IETF ALTO ; 
alto-cha...@ietf.org; alto-...@ietf.org
Subject: Re: [alto] ALTO Draft ReCharter WG review - extensible set of policy 
attributes

Hi Sabine, Qin,

Good discussions.

I support the use cases of the design direction. One suggestion is to look at 
the design in a slightly abstract, general framework. In particular, the 
abstract framework looks like this to me:

- Ve: A set of "volatile" (ephemeral) variables; Ve tends to be small, 
fast-changing data;
- Vs: Another set of records that are stable and indexed by the ephemeral 
variables; Vs can be large, but stable data.

There are two channels from the network to the application:
- Channel 1 for Ve
- Channel 2 for Vs

This definitely is a generic framework supported by some existing use cases 
including what you presented.

In the general framework, Channel 1 can be ALTO or protocol specific. Since it 
is short and needs low latency, it is more likely to be protocol specific and 
embedded in some other protocol such as even data path protocols (5G, ECN bits 
in IP); channel 2 is ALTO.

A couple of points to be considered when conducting further design:
- One thing we learned from SSE is the consistency between these two channels 
(or more, as Ve can be carried by multiple channels, etc), and
- Document additional use cases beyond the demonstrated use cases.

Looking forward to talking to you (virtually) f2f tomorrow.

Richard

On Thu, Mar 11, 2021 at 5:01 AM Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>
 wrote:
Hi Qin,

Please see inline,
Thanks
Sabine

From: Qin Wu mailto:bill...@huawei.com>>
Sent: Thursday, March 11, 2021 9:32 AM
To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
mailto:sabine.randriam...@nokia-bell-labs.com>>;
 IETF ALTO mailto:alto@ietf.org>>
Cc: alto-cha...@ietf.org; 
alto-...@ietf.org
Subject: RE: ALTO Draft ReCharter WG review - extensible set of policy 
attributes

Hi, Sabine:
发件人: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) 
[mailto:sabine.randriam...@nokia-bell-labs.com]
发送时间: 2021年3月11日 1:55
收件人: Qin Wu mailto:bill...@huawei.com>>; IETF ALTO 
mailto:alto@ietf.org>>
抄送: alto-cha...@ietf.org; 
alto-...@ietf.org
主题: RE: ALTO Draft ReCharter WG review - extensible set of policy attributes

Hello ALTO WG,

Regarding the proposed work item on “Protocol extensions to support a richer 
and extensible set of policy attributes in ALTO information update request and 
response” (GPE for short) , I would like to add the following:

This work item can be useful, among others, to allow a UE getting cellular 
network KPIs from an ALTO Server, to figure out for example whether the cell is 
congested, or which cell to choose.

An ALTO Server cannot provide real-time information. With the proposed 
extensions, it can indicate a number of real-time network parameters against 
which ALTO cost values can be modulated.

[Qin]: Yes, the current ALTO server can only provide non-real time or near real 
time information, performance metrics work allows ALTO server expose 
performance data. If ALTO protocol is extended to support pub sub mechanism,
Providing real time information will not be an issue.

But I agree in many cases, providing real time information is not necessary, 
e.g., cloud gaming use case provided Tencent and china mobile, their case is 
different from your proposed case, they will use cloud gaming server as ALTO 
client to get needed information.
[ [SR] ] indeed, an ALTO client (AOC for short) can be beneficially integrated 
with a cloud gaming server (CGS for short) . In that case, the ALTO information 
provided by the ALTO Server (AOS for short) can be made aware of given specific 
parameters captured by the CGS at a different pace. This may speed up the 
process as well.

These parameters are received by UEs directly from the network and not from 
ALTO. The UE receives an array of ALTO cell KPI values that each depend on the 
value of a parameter. The UE can pick the  ALTO value corresponding to the 
value of the real-time parameter received from the network. Thus, the UE 
modulates the received ALTO values in real-time.

[Qin]: your case is UE centric solution, UE gets network KPI from ALTO server 
and get real time parameter from another data source in the Network, what is 
not clear is how real time parameter is correlated with Network KPI information 
within UE.
Also the interface between UE and RAN is not in the scope of ALTO work, I think.
[ [SR] ] definitely, the scope of the extension restricts to exchanges between