[alto] I-D Action: draft-ietf-alto-incr-update-sse-09.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Application-Layer Traffic Optimization WG of 
the IETF.

Title   : ALTO Incremental Updates Using Server-Sent Events 
(SSE)
Authors : Wendy Roome
  Y. Richard Yang
  Shiwei Dawn Chen
Filename: draft-ietf-alto-incr-update-sse-09.txt
Pages   : 44
Date: 2018-03-01

Abstract:
   The Application-Layer Traffic Optimization (ALTO) [RFC7285] protocol
   provides network related information, called network information
   resources, to client applications so that clients can make informed
   decisions in utilizing network resources.  For example, an ALTO
   server can provide network and cost maps so that an ALTO client can
   use the maps to determine the costs between endpoints when choosing
   communicating endpoints.

   However, the ALTO protocol does not define a mechanism to allow an
   ALTO client to obtain updates to the information resources, other
   than by periodically re-fetching them.  Because some information
   resources (e.g., the aforementioned maps) may be large (potentially
   tens of megabytes), and because only parts of the information
   resources may change frequently (e.g., only some entries in a cost
   map), complete re-fetching can be extremely inefficient.

   This document presents a mechanism to allow an ALTO server to push
   updates to ALTO clients, to achieve two benefits: (1) Updates can be
   immediate, in that the server can send updates as soon as they are
   available; and (2) updates can be incremental, in that if only a
   small section of an information resource changes, the server can send
   just the changes.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-incr-update-sse/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-alto-incr-update-sse-09
https://datatracker.ietf.org/doc/html/draft-ietf-alto-incr-update-sse-09

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-incr-update-sse-09


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

[alto] I-D Action: draft-ietf-alto-unified-props-new-02.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Application-Layer Traffic Optimization WG of 
the IETF.

Title   : Unified Properties for the ALTO Protocol
Authors : Wendy Roome
  Shiwei Dawn Chen
  Sabine Randriamasy
  Y. Richard Yang
  Jingxuan Jensen Zhang
Filename: draft-ietf-alto-unified-props-new-02.txt
Pages   : 27
Date: 2018-03-01

Abstract:
   This document extends the Application-Layer Traffic Optimization
   (ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint
   properties" to other entity domains, and by presenting those
   properties as maps, similar to the network and cost maps in ALTO.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-alto-unified-props-new-02
https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto

Re: [alto] unified-props, cellular addresses and path-vector - registry

[Jensen Zhang]

Hi Sabine, all

Let me post some considerations on this topic. Please see my comments
inline.

On Wed, Feb 28, 2018 at 6:17 AM Randriamasy, Sabine (Nokia -
FR/Paris-Saclay)  wrote:

> Hi Jensen, Kai, Vijay, all
>
>
>
> Thanks all for this discussion on registries, which needs a separate
> thread so I added “registry” to the initial thread.
>
> The ALTO Entity Domain Registry of the Unified Properties (UP) draft is to
> be seen as an extension of the ALTO Address Type Registry specified in RFC
> 7285. Indeed ipv4 and ipv6 map to both ALTO Address Type and ALTO Domain
> Type where the latter set covers the first one.
>
>
>
Yes. I think the goal of the ALTO Entity Domain Registry is to be an
extension of the ALTO Address Type Registry. But the relationship between
these two registries need to be clarified in the documents.


> Definitely, Jensen’s explanations (items 1) and 2) ) in his e-mail of Feb
> 27, 2018 at 3:10 PM should be used in sections 2.7 or 9.2 of the UP draft
> to clarify the relation between both.
>
>
>
Yes, agree. I will edit it.


> For section 9.2  of the UP draft, I agree with Jensen’s views and
> understand Kai’s concerns. We may consider adding a sentence generalized
> from Sections 3.1.1.2 and 3.1.2.2 to have something like :
>
> "When a new address type is registered in the ALTO Address Type Registry
> of [RFC7285], the same identifier MUST be also registered in the ALTO
> Entity Domain Registry. And the Entity Address Encoding for this entity
> domain identifier MUST cover both Address Encoding and Prefix Encoding of
> the same identifier registered in the ALTO Address Type Registry [RFC7285]."
>
> “For the purpose of defining properties, an individual Entity address and
> the corresponding full-length prefix are considered aliases for the same
> entity.”
>
>
>
Yes, such a sentence is helpful.


> Would this help addressing the issue?
>
>
Yes, enforce address type registered as entity domain can help to guarantee
consistency. But I think it is not enough.

Considering a prior document registers a new entity domain called 'AAA'
first, the 'AAA' can be a valid entity domain but not a valid address type
at this moment. Then, another later document registers a new address type
also called 'AAA'. If the encoding of the address type 'AAA' is not
consistent with the encoding of the entity domain 'AAA', there will be some
issue.

So I propose we add a new column in the ALTO Entity Domain Registry table,
maybe called 'Valid for ALTO Addresses', to indicate which entity domain
can also be used as an address type and which cannot. Those entity domains
marked as 'Valid for ALTO Addresses' don't have to be registered in ALTO
Address Type Registry again. In this way, we can make 'ALTO Entity Domain
Registry' a superset of 'ALTO Address Type Registry'. But of course, other
columns of the ALTO Entity Domain Registry should be adjusted to
distinguish individual address encoding from the prefix/block address
encoding.

Any thougthts?

Thanks,
Jensen


>
> Thanks,
>
> Sabine
>
>
>
>
>
>
>
> *From:* alto [mailto:alto-boun...@ietf.org] *On Behalf Of *Jensen Zhang
> *Sent:* Tuesday, February 27, 2018 10:11 AM
> *To:* Kai Gao 
> *Cc:* alto@ietf.org
> *Subject:* Re: [alto] unified-props, cellular addresses and path-vector
>
>
>
> Hi Kai,
>
> Thanks for your comment. See inline.
>
> On Tue, Feb 27, 2018 at 4:38 PM Kai Gao 
> wrote:
>
> Hi Jensen,
>
> Please see inline.
>
>
>
> On 02/27/2018 03:44 PM, Jensen Zhang wrote:
>
> Hi all,
>
>
>
> Continue the discussion above. I suggest modifying the first paragraph of
> page 26 of draft-ietf-alto-unified-props-new-01
>
>
>
> "It is RECOMMANDED that a new ALTO entity domain be registered when the
> corresponding address type is registered based on ALTO Address Type
> Registry [RFC7285]."
>
>
>
> as the following:
>
>
>
> "When a new address type is registered in the ALTO Address Type Registry
> [RFC7285], the same identifier MUST be also registered in the ALTO Entity
> Domain Registry. And the Entity Address Encoding of this entity domain
> identifier MUST include both Address Encoding and Prefix Encoding of the
> same identifier registered in the ALTO Address Type Registry [RFC7285]."
>
> It might be odd to have two encodings for a single entry. Since address
> encoding is actually a special case of prefix encoding, maybe we can use
> prefix encoding alone?
>
>
>
> The words may need to be revised. But we indeed hope to accept both
> Address Encoding and Prefix Encoding as the valid Entity Address Encoding.
> Using prefix encoding alone is not consistent with what "ipv4" and "ipv6"
> domain do in Section 3.1 of draft-alto-unified-props-new-01.
>
>
>
>
>
> Any comment?
>
>
>
>
>
> On Tue, Feb 27, 2018 at 3:10 PM Jensen Zhang 
> wrote:
>
> Hi Vijay,
>
> It is a good point to explain the relationship of "ALTO Address Type
> Registry" and