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

[Gao Kai <[e-mail]>]

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 <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>     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. 
>>
>>     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
>>     <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
>>       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
>>     <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=>
>     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. 
>
>
> 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
>>
>>
>>     _______________________________________________
>>     alto mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://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 <[e-mail] <mailto:[e-mail]>>   |
> | Professor of Computer Science       |
> | http://www.cs.yale.edu/~yry/ <http://www.cs.yale.edu/%7Eyry/>        |
>  =====================================