Subject: [alto] Path vector to support application traffic capacity region design

From: "Y. Richard Yang" <[email-masked]>
Date: Thu, 7 Jul 2016 17:50:31 -0400

Dear all,

We have made an initial design of the path vector design to support the key
application capacity region use case.

Below is a list of key design reasoning:
- Current cost map and endpoint cost service is designed for the setting of
alternative flows, in that it asks for the cost of each flow alone, but the
capacity region is for concurrent flows. Hence, we need a new request
parameter to denote the new semantics---we could use a new cost mode, but
using a new design can be cleaner.

- We want to support both endpoints and network maps (PIDs), when querying
capacity regions. Hence, the query, as an example possibility, is:

  POST /capacityregion/lookup HTTP/1.1
  Host: alto.example.com
  Content-Length: TBD
  Content-Type: application/alto-flowparams+json
  Accept: application/alto-costmap+json,application/alto-error+json

  {
    "cost-type" : {"cost-mode": "path-vector",
                         "cost-metric": "bandwidth"
    },
    "flows" : [
      {"src": "ipv4:192.0.2.2", "dst": "ipv4:192.0.2.89"},
      {"src": "ipv4:192.0.2.2", "dst": "ipv4:198.51.100.34"},
      {"src": "ipv4:192.0.2.2", "dst": "ipv4:203.0.113.45"},
      {"src": "ipv4:192.0.2.3", "dst": "ipv4:203.0.113.45"}
    ]
  }

A possible encoding of response is:

  HTTP/1.1 200 OK
  Content-Length: TBA
  Content-Type: application/alto-costmap+json

  {
      "dependent-vtags" : [    // defines the resource id providing nep
        { "resource-id": "my-nep-map",
          "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
        }
      ],

      "meta" : {
       "vtag" : {
           "resource-id": "my-costmap",
           "tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"
        }
      "cost-type" : {"cost-mode": "path-vector",
                     "cost-metric": "bandwidth"
    },

    "cost-map" : {
      "ipv4:192.0.2.2": {
                "ipv4:192.0.2.89":    ["ne56"],
                "ipv4:198.51.100.34": ["ne56", "ne57"],
                "ipv4:203.0.113.45":  ["ne57"]
      },
      "ipv4:192.0.2.3": {
                "ipv4:203.0.113.45":  ["ne57"]
      }
    }
  }

The remaining issue is how to obtain the properties of the abstract network
elements. For this, we propose to use the unified properties design:
https://tools.ietf.org/html/draft-roome-alto-unified-props-00

Any comments?

Cheers,
Richard

---

From: Gao Kai <[email-masked]>
Date: Fri, 8 Jul 2016 10:35:31 +0800

Hi Richard and all,

Please see my comments inline.

Regards,
Kai

On 08/07/16 05:50, Y. Richard Yang wrote:
> Dear all,
>
> We have made an initial design of the path vector design to support
> the key application capacity region use case. 
>
> - Current cost map and endpoint cost service is designed for the
> setting of alternative flows, in that it asks for the cost of each
> flow alone, but the capacity region is for concurrent flows. Hence, we
> need a new request parameter to denote the new semantics---we could
> use a new cost mode, but using a new design can be cleaner.
>
> - We want to support both endpoints and network maps (PIDs), when
> querying capacity regions. Hence, the query, as an example
> possibility, is:
>
>   Host: alto.example.com <http://alto.example.com>
>   Content-Length: TBD
> The remaining issue is how to obtain the properties of the abstract
> network elements. For this, we propose to use the unified properties
> design:
That doesn't seem like a good idea.

First, the "network elements" are very likely to be request-specific,
e.g., the element IDs are meaningful only for the given request while
the unified property service is using a global namespace.
Even if we can live with globally unique element IDs, ALTO clients may
query the properties of network elements from different queries.  That
can be quite confusing so we'd probably have to make it clear that this
must not be done.  And the whole thing can lead to extra complexities to
understand and implement the service.

Second, using a second query may lead to inconsistency, even though the
failure scenario may not be a big deal if the clients are not using
incremental updates.  However, it does require extra storage on the
server to store the data when the clients are making one-shot queries. 
Of course, for the targeted scenario where flows have large volumes,
one-shot queries are definitely not encouraged.

One options, of course, is to encode the elements in the response. 
However, if UPS is desired, I suggest using a query-specific one instead
of a global one, like the stream control URI used in the SSE draft.
> Any comments?
>
> Cheers,
> Richard
>
>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 8 Jul 2016 12:11:46 -0400

Hi Kai,

On Thu, Jul 7, 2016 at 10:35 PM, Gao Kai <[email-masked]>
wrote:

> We have made an initial design of the path vector design to support the
> key application capacity region use case.
>
> - Current cost map and endpoint cost service is designed for the setting
> of alternative flows, in that it asks for the cost of each flow alone, but
> the capacity region is for concurrent flows. Hence, we need a new request
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__alto.example.com&d=CwMD-g&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=c7YHdBafx9Hhdqqb8Cn47RLAJcr6jjZs_orqdAOojPw&s=kmAR7JkZey89dhUxg429u46yO5rn0DYUb1Q-XKIm924&e=>
>   Content-Length: TBD
> network elements. For this, we propose to use the unified properties design:
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Droome-2Dalto-2Dunified-2Dprops-2D00&d=CwMD-g&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=c7YHdBafx9Hhdqqb8Cn47RLAJcr6jjZs_orqdAOojPw&s=kpwxnZwaBbAmP5fl-gMCGJjKZzWkK4GalhqS9Mm1vw0&e=>
>
> e.g., the element IDs are meaningful only for the given request while the
> unified property service is using a global namespace.
> query the properties of network elements from different queries.  That can
> be quite confusing so we'd probably have to make it clear that this must
> not be done.  And the whole thing can lead to extra complexities to
> incremental updates.  However, it does require extra storage on the server
> to store the data when the clients are making one-shot queries.  Of course,
> for the targeted scenario where flows have large volumes, one-shot queries
> are definitely not encouraged.
>

Excellent comments! My original intention was to separate the path vectors
from the vector-element properties so that the property updates can be
through a different channel. You made an excellent point and I agree that
encoding in the same makes more sense.

Richard

> alto mailing [email-masked]://www.ietf.org/mailman/listinfo/alto <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=CwMD-g&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=c7YHdBafx9Hhdqqb8Cn47RLAJcr6jjZs_orqdAOojPw&s=KAyMDy4aMsmOVHWJCPmyzWU9GnX9L-dWUW3Rnxv2Lig&e=>
>
>
>

-- 
-- 
 =====================================
| Y. Richard Yang <[email-masked]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================

---

From: Gao Kai <[email-masked]>
Date: Sat, 9 Jul 2016 13:24:38 +0800

Hi Richardand all,

Putting properties in another service may not be that bad.  Consider the
network map and cost map, where inconsistency may also occur, the "tag"
can be used by the clients to make sure the two resources are
consistent.  I think for path vectors, similar mechanisms can be
introduced too.

My concern would be that a global network element map may not be
desirable.  However, a customized network element map can be handy,
especially if incremental update is involved where the incremental
update service can provide some kind of synchronization.

I think the similarity between path vector and network/cost maps may
help us understand the relationship between the graph representation and
the current ALTO abstraction.

Regards,
Kai

On 09/07/16 00:11, Y. Richard Yang wrote:
> Hi Kai,
>
> On Thu, Jul 7, 2016 at 10:35 PM, Gao Kai <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Richard and all,
>
>>     We have made an initial design of the path vector design to
>>     support the key application capacity region use case. 
>>
>>     setting of alternative flows, in that it asks for the cost of
>>     each flow alone, but the capacity region is for concurrent flows.
>>     Hence, we need a new request parameter to denote the new
>>     semantics---we could use a new cost mode, but using a new design
>>     can be cleaner.
>>
>>     The remaining issue is how to obtain the properties of the
>>     abstract network elements. For this, we propose to use the
>>     unified properties design:
>     First, the "network elements" are very likely to be
>     request-specific, e.g., the element IDs are meaningful only for
>     the given request while the unified property service is using a
>     global namespace.
>     Even if we can live with globally unique element IDs, ALTO clients
>     may query the properties of network elements from different
>     queries.  That can be quite confusing so we'd probably have to
>     make it clear that this must not be done.  And the whole thing can
>     lead to extra complexities to understand and implement the service.
>
>     Second, using a second query may lead to inconsistency, even
>     though the failure scenario may not be a big deal if the clients
>     are not using incremental updates.  However, it does require extra
>     storage on the server to store the data when the clients are
>     making one-shot queries.  Of course, for the targeted scenario
>     where flows have large volumes, one-shot queries are definitely
>     not encouraged.
>
> Excellent comments! My original intention was to separate the path
> vectors from the vector-element properties so that the property
> updates can be through a different channel. You made an excellent
> point and I agree that encoding in the same makes more sense. 
>
> Richard
>  
>
>     However, if UPS is desired, I suggest using a query-specific one
>     instead of a global one, like the stream control URI used in the
>     SSE draft.
>>     Any comments?
>>
>>     Cheers,
>>     Richard
>>
>>
>>     [email-masked] <mailto:[email-masked]>
>>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=CwMD-g&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=c7YHdBafx9Hhdqqb8Cn47RLAJcr6jjZs_orqdAOojPw&s=KAyMDy4aMsmOVHWJCPmyzWU9GnX9L-dWUW3Rnxv2Lig&e=>
>
>
>
>
> -- 
> -- 
> | Y. Richard Yang <[email-masked] <mailto:[email-masked]>>   |
> | http://www.cs.yale.edu/~yry/ <http://www.cs.yale.edu/%7Eyry/>        |