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

["Y. Richard Yang" <[e-mail]>]

Hi Kai,

On Thu, Jul 7, 2016 at 10:35 PM, Gao Kai <[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 [e-mail]://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]>   |
| Professor of Computer Science       |
| http://www.cs.yale.edu/~yry/        |
 =====================================