Re: [alto] ALTO Cost calendars in wireless access networks

Hi Uwe,

Please see inline.

On Thu, Nov 13, 2014 at 7:41 PM, Rauschenbach, Uwe (NSN - DE/Munich) <
uwe.rauschenbach@nsn.com> wrote:

>  Hi Xiao,
>
>
>
> Thanks for your feedback and the pointers.
>
>
>
> I have looked at I-D-pid-properties and possibly it can be used to build
> the solution (cell Id as a PID property). However, I am not clear about how
> PID properties can be used in queries, e.g. “what is the cost from PID with
> cellid=X to node Y”. Maybe this can be realized by first getting the
> (potentially large) PID map of the cells in the area, store it and then
> query the individual PIDs. But I have concern about the data volume. It may
> be better to have an extension to the query mechanism to consider a list of
> PID properties as filter in actual cost queries.
>

I agree with your concern on the data volume. So the scenario you mentioned
is when a client is trying to find out the cost between two endpoints (one
with cellid=X and another with cellid=Y), is this correct?

With your Solution A (i.e. a cellular access point defined as an endpoint),
the client could use the endpoint cost service (
http://tools.ietf.org/html/draft-roome-alto-pid-properties-02#section-4.4),
which is simple. With your Solution B, either the client needs to do what
you mentioned (get a potentially large PID map then query for cost) or we
could extend the PID properties service with a reverse lookup mechanism.

This largely depends on how endpoints, PIDs map to cell-IDs (e.g.,
one-to-one, one-to-many, etc.), and how they might change as the location
of the client changes. What do you think?

>
>
> I agree that a push mechanism is beneficial in environments with dynamic
> content such as mobile.  I have to look deeper into the concrete SSE
> mechanism w.r.t. mobile, but here are some preliminary thoughts: One
> complication may be the design decision documented in section 7.1. In
> mobile, loss and re-establishment of connection is not unusual; just
> sending the whole map again on re-connect will not be efficient as it may
> happen too often. Also, SSE may have problems with some Web caching
> architectures as documented in RFC6202 section 3.2; it may be necessary to
> use long polling instead (which means we may run frequently into the issue
> documented in section 7.1).
>
>
>
> Altogether it may be beneficial to define the method of ALTO incremental
> updates independent from the transport of the update. Then various PUSH
> methods such as SSE, long polling, webpush (
> http://datatracker.ietf.org/wg/webpush/charter/), even WebSockets can be
> used as a transport mechanism for server-initiated updates; and the method
> could even be used to optimize updates that are initiated by the client.
> And, as said above, for mobile a better handling of connection breakdown
> and re-establishment would be needed in order for this mechanism to really
> provide savings.
>

Wendy, Richard, and I were actually discussing how SSE mechanism would work
without sending the full resource upon connection and separating the
updates from their transport. It's not fully flashed out yet (hence not in
the -00 doc), but it's certainly on our radar. I will look into some of the
other mechanisms you suggested.

Thanks,
Xiao

>
>
> Kind regards,
> Uwe
>
>
>
> *From:* boxs.jq@gmail.com [mailto:boxs.jq@gmail.com] *On Behalf Of *ext
> Xiao SHI
> *Sent:* Tuesday, November 11, 2014 8:38 PM
> *To:* Rauschenbach, Uwe (NSN - DE/Munich)
> *Cc:* ext RANDRIAMASY, SABINE (SABINE); IETF ALTO
> *Subject:* Re: [alto] ALTO Cost calendars in wireless access networks
>
>
>
> Hi Uwe,
>
>
>
> Your document sounds like a very reasonable and useful extension. Just
> have two related thoughts:
>
>
>
> 1. Have you considered your cells extension using PID properties? The
> relevant draft is here:
> http://tools.ietf.org/html/draft-roome-alto-pid-properties-02#section-4.2
> I believe the PID property document provides a solution to both
> requirements in your document (via Solution B).
>
>
>
> 2. Since the nodes change cells frequently, do you think this extension
> would benefit from incremental updates? The incr update document (
> http://datatracker.ietf.org/doc/draft-roome-alto-incr-update-sse/)
> provides the SSE framework, but I am not sure how convenient SSE is to
> mobile networks.
>
>
>
> Best,
>
> Xiao
>
>
>
> On Tue, Nov 11, 2014 at 10:23 PM, Rauschenbach, Uwe (NSN - DE/Munich) <
> uwe.rauschenbach@nsn.com> wrote:
>
> Hi Sabine,
>
>
>
> Thanks for the pointer. Yes, I think your proposal will meet the
> expectations of the sketched use cases.
>
> In fact, our proposal is orthogonal and tries to address the problem that
> in mobile networks, the network attachment
>
> point can be one additional important parameter that should be addressed
> in ALTO.
>
>
>
> So far, ALTO helps to decide “where to connect to” (where: the endpoint
> that provides the service).
>
> The cost calendar enhances this to become “when and where to connect to”.
>
> In mobile, the whole picture would become “via which cell/access, when and
> where to connect to”.
>
>
>
> Kind regards,
> Uwe
>
>
>
>
>
> *From:* ext RANDRIAMASY, SABINE (SABINE) [mailto:
> sabine.randriamasy@alcatel-lucent.com]
> *Sent:* Tuesday, November 11, 2014 8:36 AM
> *To:* Rauschenbach, Uwe (NSN - DE/Munich)
> *Cc:* IETF ALTO
> *Subject:* ALTO Cost calendars in wireless access networks
>
>
>
> Hi Uwe,
>
>
>
> I see that your draft
> http://tools.ietf.org/id/draft-rauschenbach-alto-wireless-access-00.txt
> will be presented in the next ALTO WG session.
>
>
>
> Given that your draft poses the need for a calendar in its following
> sections 3.2.1.  Cost calendar to extend battery life for background tasks
> and section 3.2.2.  Cost calendar to optimize application sessions, you may
> want to look at
> http://tools.ietf.org/id/draft-randriamasy-alto-cost-calendar-02.txt,
> that proposes ALTO cost calendars and will be presented during the ALTO WG
> session as well, as it would be interesting to see how this proposal may
> meet your expectations.
>
>
>
> Best regards,
>
> Sabine
>
>
>
>
> _______________________________________________
> alto mailing list
> alto@ietf.org
> https://www.ietf.org/mailman/listinfo/alto
>
>
>