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 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.

Kind regards,
Uwe

From: [email protected] [mailto:[email protected]] 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) 
<[email protected]<mailto:[email protected]>> 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:[email protected]<mailto:[email protected]>]
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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/alto

_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto

Reply via email to