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

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Tue, 11 Nov 2014 18:35:38 +0000

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

---

From: "Rauschenbach, Uwe (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 12 Nov 2014 03:23:24 +0000

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-masked]]
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,

Best regards,
Sabine

---

From: Xiao SHI <[email-masked]>
Date: Wed, 12 Nov 2014 01:37:59 -0500

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-masked]> wrote:

> In fact, our proposal is orthogonal and tries to address the problem that
> in mobile networks, the network attachment
>
> 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-masked]]
> *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-masked]
> https://www.ietf.org/mailman/listinfo/alto
>
>

---

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Wed, 12 Nov 2014 15:39:39 +0000

Hi Xiao and Uwe,

The cellular or other access use case also calls I think for looking at related ALTO Service deployment cases.
Best,
Sabine

De : [email-masked] [mailto:[email-masked]] De la part de Xiao SHI
Envoyé : mercredi 12 novembre 2014 07:38
À : Rauschenbach, Uwe (NSN - DE/Munich)
Cc : RANDRIAMASY, SABINE (SABINE); IETF ALTO
Objet : 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-masked]<mailto:[email-masked]>> wrote:
Hi Sabine,

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-masked]<mailto:[email-masked]>]
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,

Best regards,
Sabine

_______________________________________________
alto mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/alto

---

From: "Rauschenbach, Uwe (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 14 Nov 2014 00:05:32 +0000

Hi Sabine,

Is http://tools.ietf.org/html/draft-ietf-alto-deployments-10 the appropriate place to add these?

Kind regards,
Uwe

From: ext RANDRIAMASY, SABINE (SABINE) [mailto:[email-masked]]
Sent: Wednesday, November 12, 2014 5:40 AM
To: Xiao SHI; Rauschenbach, Uwe (NSN - DE/Munich)
Cc: IETF ALTO
Subject: RE: [alto] ALTO Cost calendars in wireless access networks

Hi Xiao and Uwe,

De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] De la part de Xiao SHI

Hi Uwe,

Best,
Xiao

Kind regards,
Uwe

Hi Uwe,

Best regards,
Sabine

---

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Fri, 14 Nov 2014 00:15:03 +0000

Hi Uwe,

It would be interesting indeed to see whether the editors of this draft have an interest in “Map Examples for Different Types of ISPs” with cellular/wireless networks.

Best regards

Sabine

De : Rauschenbach, Uwe (NSN - DE/Munich) [mailto:[email-masked]]
Envoyé : vendredi 14 novembre 2014 01:06
À : RANDRIAMASY, SABINE (SABINE); Xiao SHI
Cc : IETF ALTO
Objet : RE: [alto] ALTO Cost calendars in wireless access networks

Hi Sabine,

Kind regards,
Uwe

Hi Xiao and Uwe,

Hi Uwe,

Best,
Xiao

Kind regards,
Uwe

Hi Uwe,

Best regards,
Sabine

---

From: "Rauschenbach, Uwe (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 14 Nov 2014 00:41:17 +0000

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-masked] [mailto:[email-masked]] 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,

Best,
Xiao

Kind regards,
Uwe

Hi Uwe,

Best regards,
Sabine

---

From: Xiao SHI <[email-masked]>
Date: Thu, 13 Nov 2014 21:57:46 -0500

Hi Uwe,

Please see inline.

On Thu, Nov 13, 2014 at 7:41 PM, Rauschenbach, Uwe (NSN - DE/Munich) <
[email-masked]> wrote:

> 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:* [email-masked] [mailto:[email-masked]] *On Behalf Of *ext
> Xiao SHI
> *Sent:* Tuesday, November 11, 2014 8:38 PM
> *Cc:* ext RANDRIAMASY, SABINE (SABINE); IETF ALTO
> *Subject:* Re: [alto] ALTO Cost calendars in wireless access networks
>
>
>
> Hi Uwe,
>
>
>
> 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).
>
>
>
> 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
>
>
>

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Fri, 14 Nov 2014 15:36:41 +0000

Hi Uwe, all,

Personally, I am not sure whether a single RAN cell is indeed the right granularity for PIDs.

But draft-ietf-alto-deployments is a WG document and in general the editors have been open to suggestions for further realistic deployment cases of ALTO. draft-ietf-alto-deployments has some text already on mobile access networks, albeit at a much larger granularity of PIDs.

As usual in the IETF: Propose specific text ;)

Best regards

Michael

From: alto [mailto:[email-masked]] On Behalf Of Rauschenbach, Uwe (NSN - DE/Munich)
Sent: Friday, November 14, 2014 1:06 AM
To: RANDRIAMASY, SABINE (SABINE); Xiao SHI
Cc: IETF ALTO
Subject: Re: [alto] ALTO Cost calendars in wireless access networks

Hi Sabine,

Kind regards,
Uwe

Hi Xiao and Uwe,

Hi Uwe,

Best,
Xiao

Kind regards,
Uwe

Hi Uwe,

Best regards,
Sabine

---

From: "RANDRIAMASY, SABINE (SABINE)" <[email-masked]>
Date: Fri, 14 Nov 2014 16:31:48 +0000

Hi Michael, Uwe, Xiao, all

Indeed the primary scope of a PID way way beyond the cell level. On the other hand, we may also look at section
2.2.3 More Advanced Deployments

There are also different options regarding the guidance offered by an ALTO service
2. Cascaded servers: An ALTO server may itself include an ALTO
       client and query other ALTO servers, e.g., for certain
       destinations.

Michael is right, let’s see if we can formalize  an ALTO topology of a cellular/wireless network.

Best regards,
Sabine

De : Scharf, Michael (Michael)
Envoyé : vendredi 14 novembre 2014 16:37
À : Rauschenbach, Uwe (NSN - DE/Munich); RANDRIAMASY, SABINE (SABINE); Xiao SHI
Cc : IETF ALTO
Objet : RE: [alto] ALTO Cost calendars in wireless access networks

Hi Uwe, all,

Best regards

Michael

Hi Sabine,

Kind regards,
Uwe

Hi Xiao and Uwe,

Hi Uwe,

Best,
Xiao

Kind regards,
Uwe

Hi Uwe,

Best regards,
Sabine