Subject: [DMM] OnDemand draft: 3 address types discussion

From: "Moses, Danny" <[email-masked]>
Date: Tue, 3 May 2016 12:27:00 +0000

This is in reply to comments we received from Behcet and Suresh regarding the three types of addresses define in the draft. Suresh commented that the 'Fixed IP address' is not necessary and application only require to select Sustained or Nomadic IP addresses and Behcet commented that the 'Sustained IP address' is not needed and not well define due to the fact that the draft does not define how to identify the end of an IP session (will be discussed in a separate email).
We have gave more thought to these types and concluded that the definitions in the spec were confusing. We are providing new text in the new version, hoping they are more clear.
We re-evaluated whether to stay with the definition of three IP address types or move to a two IP address type scheme and eventually concluded that it is better to stay with the three type alternative. We hope that the better text in the new draft version will clarify and here are some additional inputs:
Nomadic IP address (or in its new name: Non-persistent IP address):
Clearly this type is useful for all applications that do not require any IP session continuity guarantee from the network and wish to avoid the overhead introduced by the network as part of that guarantee (inefficient routes, tunneling etc...).
Sustained IP address (or in its new name: Session-lasting IP address):
This is our accurate definition for the IP session continuity service that some application require and is similar to what is provided today by default, by mobile operators via GTP or PMIP. Basically, current implementations provide  a guarantee for the source IP address to be valid throughout the time the mobile host is connected to the mobile network.
We concluded that mobile hosts do not really require such a guarantee. It is sufficient to require a guarantee of the IP address availability while there is/are an IP session(s) using this IP address and hence the more accurate definition. Furthermore, some WG members have shown cases in DMM where it is more efficient for applications to request a new Session-lasting IP address when launched rather than using an existing one that was allocated to the mobile host in the past. This is due to possible movement of the mobile host to a LAN which is being served by a mobility anchor that is different from the one that was used when the older Session-lasting IP address was assigned to the mobile host.
Fixed IP address (no renaming ...):
We believe that this is where our original text was the most unclear leading to the confusion on the mailing list and the comments from the flour. A Fixed IP address is guaranteed by the network to Always be valid, even if the mobile host is not utilizing any IP sessions, or has been disconnected from the network for some time. This is a special service that mobile network operators provide for a premium charge, for servers, VPNs , secured content and other applications. With this IP address type the network operator provide IP address reachability in addition to IP session continuity, and mobile hosts may register these addresses in DNS infrastructure for name resolution.
Clearly, most mobile hosts do not require Fixed IP addresses and their owners will not pay the premium cost for this service, but still, it is a service that mobile operators provide and this is enough proof for us to acknowledge its need. Please see some examples from
AT&T -  https://www.wireless.att.com/businesscenter/solutions/connectivity/ip-addressing.jsp,
Verizon -  http://www.verizonwireless.com/businessportals/support/features/data_services/static_ip.html
 and Sprint -  https://www.sprint.com/business/solutions/sprint_enablers/sprint_datalink_and_static_ip/index.html#.VxC7xSN9480<https://www.sprint.com/business/solutions/sprint_enablers/sprint_datalink_and_static_ip/index.html>
 providing this service (which is called: Static IP address)
Regards,
Alper and Danny

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 6 May 2016 14:20:42 -0500

Hi Danny,

This is my reply to all your mails. I hope it clarifies the air.

I read RFC 5014 and I think that on-demand mobility as I and it seems
like as 3GPP understands is already there:

IPV6_PREFER_SRC_HOME
IPV6_PREFER_SRC_COA

are all we need.
So if UE wants mobility, it sets  IPV6_PREFER_SRC_HOME and as a result
gets the fixed IP address as you call it or it gets anchored mobility
service.

If UE does not want mobility, it sets IPV6_PREFER_SRC_COA then it gets
the nomadic IP address.

Note that in the case of mobility, UE may still get nomadic address
and mobility, that is another issue.

Therefore RFC 5014 is good enough, the authors, all good friends of
this community have done a good job.

Regards,

Behcet

On Tue, May 3, 2016 at 7:27 AM, Moses, Danny <[email-masked]> wrote:
>
> This is in reply to comments we received from Behcet and Suresh regarding
> the three types of addresses define in the draft. Suresh commented that the
> ‘Fixed IP address’ is not necessary and application only require to select
> Sustained or Nomadic IP addresses and Behcet commented that the ‘Sustained
> IP address’ is not needed and not well define due to the fact that the draft
> does not define how to identify the end of an IP session (will be discussed
> in a separate email).
> We have gave more thought to these types and concluded that the definitions
> in the spec were confusing. We are providing new text in the new version,
> hoping they are more clear.
> We re-evaluated whether to stay with the definition of three IP address
> types or move to a two IP address type scheme and eventually concluded that
> it is better to stay with the three type alternative. We hope that the
> better text in the new draft version will clarify and here are some
> additional inputs:
> Clearly this type is useful for all applications that do not require any IP
> session continuity guarantee from the network and wish to avoid the overhead
> introduced by the network as part of that guarantee (inefficient routes,
> tunneling etc…).
> This is our accurate definition for the IP session continuity service that
> some application require and is similar to what is provided today by
> default, by mobile operators via GTP or PMIP. Basically, current
> implementations provide  a guarantee for the source IP address to be valid
> throughout the time the mobile host is connected to the mobile network.
> We concluded that mobile hosts do not really require such a guarantee. It is
> sufficient to require a guarantee of the IP address availability while there
> is/are an IP session(s) using this IP address and hence the more accurate
> definition. Furthermore, some WG members have shown cases in DMM where it is
> more efficient for applications to request a new Session-lasting IP address
> when launched rather than using an existing one that was allocated to the
> mobile host in the past. This is due to possible movement of the mobile host
> to a LAN which is being served by a mobility anchor that is different from
> the one that was used when the older Session-lasting IP address was assigned
> to the mobile host.
> Fixed IP address (no renaming …):
> We believe that this is where our original text was the most unclear leading
> to the confusion on the mailing list and the comments from the flour. A
> Fixed IP address is guaranteed by the network to Always be valid, even if
> the mobile host is not utilizing any IP sessions, or has been disconnected
> from the network for some time. This is a special service that mobile
> network operators provide for a premium charge, for servers, VPNs , secured
> content and other applications. With this IP address type the network
> operator provide IP address reachability in addition to IP session
> continuity, and mobile hosts may register these addresses in DNS
> infrastructure for name resolution.
> Clearly, most mobile hosts do not require Fixed IP addresses and their
> owners will not pay the premium cost for this service, but still, it is a
> service that mobile operators provide and this is enough proof for us to
> acknowledge its need. Please see some examples from
> AT&T -
> https://www.wireless.att.com/businesscenter/solutions/connectivity/ip-addressing.jsp,
> Verizon -
> http://www.verizonwireless.com/businessportals/support/features/data_services/static_ip.html
> and Sprint -
> https://www.sprint.com/business/solutions/sprint_enablers/sprint_datalink_and_static_ip/index.html#.VxC7xSN9480
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm
>

---

From: "Moses, Danny" <[email-masked]>
Date: Sun, 8 May 2016 11:05:57 +0000

Come on Behcet, this note from you is really insulting.
IPV6_PREFER_SRC_HOME and IPV6_PREFER_SRC_COA assumes the implementation of MIP where the mobile host is provisioned a Home Address and a Care-of Address.

But with PMIPv6 and 3GPP (GTP - to be more accurate), the mobile node is provisioned with a source IP address and the tunneling operation is performed by proxy and is transparent to the mobile host. So a mobile node cannot influence the network's tunneling operation...

Regards,
	/Danny

-----Original Message-----
From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Friday, May 06, 2016 22:21
To: Moses, Danny
Cc: [email-masked]
Subject: Re: [DMM] OnDemand draft: 3 address types discussion

Hi Danny,

I read RFC 5014 and I think that on-demand mobility as I and it seems like as 3GPP understands is already there:

IPV6_PREFER_SRC_HOME
IPV6_PREFER_SRC_COA

are all we need.
So if UE wants mobility, it sets  IPV6_PREFER_SRC_HOME and as a result gets the fixed IP address as you call it or it gets anchored mobility service.

If UE does not want mobility, it sets IPV6_PREFER_SRC_COA then it gets the nomadic IP address.

Note that in the case of mobility, UE may still get nomadic address and mobility, that is another issue.

Therefore RFC 5014 is good enough, the authors, all good friends of this community have done a good job.

Regards,

Behcet

On Tue, May 3, 2016 at 7:27 AM, Moses, Danny <[email-masked]> wrote:
>
> This is in reply to comments we received from Behcet and Suresh 
> regarding the three types of addresses define in the draft. Suresh 
> commented that the ‘Fixed IP address’ is not necessary and application 
> only require to select Sustained or Nomadic IP addresses and Behcet 
> commented that the ‘Sustained IP address’ is not needed and not well 
> define due to the fact that the draft does not define how to identify 
> the end of an IP session (will be discussed in a separate email).
> We have gave more thought to these types and concluded that the 
> definitions in the spec were confusing. We are providing new text in 
> the new version, hoping they are more clear.
> We re-evaluated whether to stay with the definition of three IP 
> address types or move to a two IP address type scheme and eventually 
> concluded that it is better to stay with the three type alternative. 
> We hope that the better text in the new draft version will clarify and 
> here are some additional inputs:
> Clearly this type is useful for all applications that do not require 
> any IP session continuity guarantee from the network and wish to avoid 
> the overhead introduced by the network as part of that guarantee 
> (inefficient routes, tunneling etc…).
> This is our accurate definition for the IP session continuity service 
> that some application require and is similar to what is provided today 
> by default, by mobile operators via GTP or PMIP. Basically, current 
> implementations provide  a guarantee for the source IP address to be 
> valid throughout the time the mobile host is connected to the mobile network.
> We concluded that mobile hosts do not really require such a guarantee. 
> It is sufficient to require a guarantee of the IP address availability 
> while there is/are an IP session(s) using this IP address and hence 
> the more accurate definition. Furthermore, some WG members have shown 
> cases in DMM where it is more efficient for applications to request a 
> new Session-lasting IP address when launched rather than using an 
> existing one that was allocated to the mobile host in the past. This 
> is due to possible movement of the mobile host to a LAN which is being 
> served by a mobility anchor that is different from the one that was 
> used when the older Session-lasting IP address was assigned to the mobile host.
> We believe that this is where our original text was the most unclear 
> leading to the confusion on the mailing list and the comments from the 
> flour. A Fixed IP address is guaranteed by the network to Always be 
> valid, even if the mobile host is not utilizing any IP sessions, or 
> has been disconnected from the network for some time. This is a 
> special service that mobile network operators provide for a premium 
> charge, for servers, VPNs , secured content and other applications. 
> With this IP address type the network operator provide IP address 
> reachability in addition to IP session continuity, and mobile hosts 
> may register these addresses in DNS infrastructure for name resolution.
> owners will not pay the premium cost for this service, but still, it 
> is a service that mobile operators provide and this is enough proof 
> for us to acknowledge its need. Please see some examples from AT&T - 
> https://www.sprint.com/business/solutions/sprint_enablers/sprint_datal
> ink_and_static_ip/index.html#.VxC7xSN9480
> providing this service (which is called: Static IP address) Regards, 
> Alper and Danny
>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 9 May 2016 10:53:31 +0200

Hi Danny,

Thank you for continuing the discussion on the 3 address types.

Le 03/05/2016 à 14:27, Moses, Danny a écrit :
> commented that the ‘Fixed IP address’ is not necessary and
> application only require to select Sustained or Nomadic IP addresses
>  and Behcet commented that the ‘Sustained IP address’ is not needed
> and not well define due to the fact that the draft does not define
> how to identify the end of an IP session (will be discussed in a
> separate email).

To me, the problem in the definitions shown in the Buenos Aires slide 4
https://www.ietf.org/proceedings/95/slides/slides-95-dmm-2.pdf
is that they dont relate to each other.  This makes that a FIXED address
could be a SUSTAINED could be a NOMADIC.

For example, a FIXED 'exists no matter where the host moves to', and a
SUSTAINED 'is valid as long as the IP session is alive'.  One does not
exclude the other.  You could have an address be NOMADIC and SUSTAINED
at the same time ('exists no matter where the host moves to' and 'valid
as long as the IP session is alive').

A definition which relates them would keep the FIXED to be 'exists no
matter where the host moves to' and NOMADIC to be 'changes in certain
places where the host moves to'.

Thus, this improved definition would not allow a FIXED _and_ NOMADIC at 
the same time.

> the new version, hoping they are more clear.

Let me see whether I can understand.

>  concluded that it is better to stay with the three type

A-ha.

> We hope that the better text in the new draft version will clarify
> and here are some additional inputs:

> any IP session continuity guarantee from the network and wish to
> avoid the overhead introduced by the network as part of that
> guarantee (inefficient routes, tunneling etc…).

> Sustained IP address (or in its new name: Session-lasting IP
> address): This is our accurate definition for the IP session
> continuity service that some application require and is similar to
> what is provided today by default, by mobile operators via GTP or
> PMIP.

These two definitions relate more to each other than the earlier
definitions, by the application requirements.

Yet, some questions arise:

The apps which don't require a session-lasting IP address can obviously 
work with a session-lasting IP address too.  So some of the 
session-lasting IP addresses can be non-persistent IP addresses?

The apps which require a session-lasting IP address wish to introduce
overhead in the network?

Mobile operators using GTP or PMIP do not provide non-persistent IP
addresses?

> Basically, current implementations provide  a guarantee for the
> source IP address to be valid throughout the time the mobile host is
> connected to the mobile network. We concluded that mobile hosts do
> not really require such a guarantee. It is sufficient to require a
> guarantee of the IP address availability while there is/are an IP
> session(s) using this IP address and hence the more accurate
> definition.

I dont understand.

Until here the app requirements where important.  Now we change to make
the mobile host to be important(?)

> Furthermore, some WG members have shown cases in DMM where it is
> more efficient for applications to request a new Session-lasting IP
> address when launched rather than using an existing one that was
> allocated to the mobile host in the past.

Well, I wonder about this.

In the environments I work I never saw an application (e.g. a browser)
to request an IP address.  It is the connection manager which deals with
address configuration.  This connection manager is not in contact with
other applications like web browsers.

> This is due to possible movement of the mobile host to a LAN which is
> being served by a mobility anchor that is different from the one that
> was used when the older Session-lasting IP address was assigned to
> the mobile host. Fixed IP address (no renaming …): We believe that
> this is where our original text was the most unclear leading to the
> confusion on the mailing list and the comments from the flour.

> A Fixed IP address is guaranteed by the network to Always be valid,
> even if the mobile host is not utilizing any IP sessions, or has been
> disconnected from the network for some time. This is a special
> service that mobile network operators provide for a premium charge,
> for servers, VPNs , secured content and other applications. With this
> IP address type the network operator provide IP address reachability
> in addition to IP session continuity, and mobile hosts may register
> these addresses in DNS infrastructure for name resolution.

I can understand the intention of the fixed IP address definition.

But I wonder whether there can be an improved definition of a fixed IP
address.  Because of the following:

A 'fixed' IP address, as much as it can be guaranteed by an operator at
a premium cost, will not be possible if moving to a more remote area:
for example, when moving from US to Europe can not maintain that fixed 
IP address even if it is paid a very high price.

> Clearly, most mobile hosts do not require Fixed IP

Again: _mobile hosts_  require?  Or apps require?

A more coherent definition can take advantage of using only app
requirements, or only mobile host reqs, or both but everywhere (i.e.
each of the 3 types of addresses relates to both MH reqs and to app reqs).

> addresses and their owners will not pay the premium cost for this
> service, but still, it is a service that mobile operators provide
> and this is enough proof for us to acknowledge its need.

> Please see some examples

Thank you very much for these pointers.  This makes it easier to 
understand the intention.

> from AT&T -
> _https://www.wireless.att.com/businesscenter/solutions/connectivity/ip-addressing.jsp_,

Is this IPv4 only?

 > Verizon -
> _http://www.verizonwireless.com/businessportals/support/features/data_services/static_ip.html_

Is this IPv4 only?

 > Sprint -
> _https://www.sprint.com/business/solutions/sprint_enablers/sprint_datalink_and_static_ip/index.html#.VxC7xSN9480_

Is this IPv4 only?

I am asking the IP version question because address configuration is 
very different in IPv6 than IPv4.

For example, in IPv6 the network does not assign an address to a host 
(as in IPv4 is done with context setup), but advertises a prefix to a 
link and the host forms an address.  In such a context the potential 
mechanism to achieve static IP addresses is very different - not only 
the network is in charge but the terminal too.

Moreover, whereas in IPv4 cellular networks the mechanism to achieve 
static IP address is standardised (NAI, PDP context setup, ppp), in IPv6 
there is no such mechanism standardised nor deployed.

Is there an example of deployed static IPv6 addresses in cellular 
networks? (as the IPv4 example of AT&T, Verizon, Sprint).  That would be 
very relevant too.

Alex

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 9 May 2016 10:36:30 -0700

Actually, IKEv2-based mechanisms did allow assigning /128 IPv6 address 
to an UE within 3GPP specs (haven't checked possible changes since 
rel-11, though). I have no idea whether this was ever implemented.

---

From: "Moses, Danny" <[email-masked]>
Date: Mon, 16 May 2016 09:58:48 +0000

Hi Alex,

Thank you very much for the detailed review and comments. I have tried to answer them, but if I was not able to be clear enough, I will be happy to discuss this with you.

I am removing parts of the previous exchange so that everyone can find the open questions and answers more easily.

Regards,
	/Danny

--------------- Text removed from previous exchange-----------------
--------------------------------------------------------------------------------

Alex >

The apps which don't require a session-lasting IP address can obviously work with a session-lasting IP address too.  So some of the session-lasting IP addresses can be non-persistent IP addresses?

Danny >
True, applications that do not require a session-lasting IP address can work correctly with a session-lasting IP address. But in that case, the network will invest resources in guaranteeing this without any real need and thus, these resources will be wasted. From the application side, its traffic may suffer from the treatment associated with providing session-lasting characteristics (non-optimal routing, encapsulation/decapsulation overhead which influences MTU, etc). Still, I believe that there will be cases when this is performed. One example is in cellular networks that automatically provide tunneling and do not support the ability to receive IP address type requests from the mobile node.

But, if an application requests a session-lasting IP address, and the network provides one, it should treat it as such - e.g. provide IP continuity guarantee throughout the lifetime of the session. The network cannot tell if the address is 'really' using the guarantee or not. 

I did not understand what you mean by 'So some of the session-lasting IP addresses can be non-persistent IP addresses?'. No, if the network provides a session-lasting IP address, it is committed to guarantee it (even if the application does not need the service).

Alex >
The apps which require a session-lasting IP address wish to introduce overhead in the network?

Danny >
Apps which require session-lasting IP addresses are apps that cannot recover from the event of source IP addresses becoming obsolete as a result of the mobile node moving to a LAN with a different IP prefix. This is why they request a session-lasting IP address. Not because they wish to introduce overhead - this is a by product...

Alex >
Mobile operators using GTP or PMIP do not provide non-persistent IP addresses?

Danny > 
Mobile operators using GTP or PMIP provide a guarantee that the source IP address they allocated to a mobile node will continue to exist (and be valid) as long as the mobile node is connected to the network (or as long as the DHCP lease condition are meat - if DHCP is used). This even a better guarantee than what we defined by 'session-lasting' IP address, because the GTP/PMIP source IP address is guaranteed regardless of the initiation/end of IP session. In our understanding, this extra guarantee is not really needed and in the DMM environment where they may be multiple mobility anchors might even introduce inefficient routing (which could be avoided in the newly introduced scheme).

To the best of my knowledge, mobile operators do not provide non-persistent IP addresses.

Alex>
> Basically, current implementations provide  a guarantee for the source 
> IP address to be valid throughout the time the mobile host is 
> connected to the mobile network. We concluded that mobile hosts do not 
> really require such a guarantee. It is sufficient to require a 

I dont understand.

Until here the app requirements where important.  Now we change to make the mobile host to be important(?)

Danny >
In current implementation a source IP address is allocated to the mobile host and is valid throughout the connection of the mobile host to the network. This is why I use the term 'mobile host' in the description that you quoted.

 We are introducing an new concept - 'OnDemand' - where each time an IP session is created (by an application running on the host), an application can request a specific source IP address for that session (with specific type). From the network's perspective, this address was allocated to a mobile host. This means that at any given time, a mobile host might have more than one source IP address allocated to in, and different IP sessions initiated by that host (by different applications running on that host) may be used in different packets being sent/received by it.

I can understand why this is confusing. If this explanation is not sufficient, I will be happy to discuss this point with you.

Alex >
> Furthermore, some WG members have shown cases in DMM where it is more 
> efficient for applications to request a new Session-lasting IP address 
> when launched rather than using an existing one that was allocated to 
> the mobile host in the past.

Danny >
Well, they did not use the term 'OnDemand' specifically, but they did show that in a distributed mobility anchor scheme, there are cases where allocating a new IP address may result in a more optimal route of the IP flow compared with using the already-allocated IP address. This is because the original IP address is served by one mobility anchor (hence all traffic must be routed through it), and after the mobile host moves to a new location, traffic may possibility be routed via a different mobility anchor which is topologically better. Once again, we can further discuss this topic).
Please refer to the following IDs:
https://datatracker.ietf.org/doc/draft-bernardos-dmm-distributed-anchoring/
https://tools.ietf.org/html/draft-seite-dmm-dma-07

Alex >
In the environments I work I never saw an application (e.g. a browser) to request an IP address.  It is the connection manager which deals with address configuration.  This connection manager is not in contact with other applications like web browsers.

Danny >
That is correct - application do not request IP addresses. This is a new concept we are introducing. Application, through the Socket interface, can indicate to the TCP/IP stack, the type of source IP address they require. The TCP/IP stack, will ether associate an existing IP address with that Socket or initiate a request to the network for a source IP address of the desired type.

Alex >
> was used when the older Session-lasting IP address was assigned to the 
> mobile host. Fixed IP address (no renaming ...): We believe that this is 
> where our original text was the most unclear leading to the confusion 
> on the mailing list and the comments from the flour.

> disconnected from the network for some time. This is a special service 
> that mobile network operators provide for a premium charge, for 
> servers, VPNs , secured content and other applications. With this IP 
> address type the network operator provide IP address reachability in 
> addition to IP session continuity, and mobile hosts may register these 
> addresses in DNS infrastructure for name resolution.

But I wonder whether there can be an improved definition of a fixed IP address.  Because of the following:

A 'fixed' IP address, as much as it can be guaranteed by an operator at a premium cost, will not be possible if moving to a more remote area:
for example, when moving from US to Europe can not maintain that fixed IP address even if it is paid a very high price.

Danny >
With the appropriate roaming implementation, even this can be achieved. But, when moving to an area where no roaming partner exists, you are correct. But this sounds to me like a business issue, not technical.

Alex >

Danny >
You are correct. Its applications, not mobile hosts...

Alex >

A more coherent definition can take advantage of using only app requirements, or only mobile host reqs, or both but everywhere (i.e.
each of the 3 types of addresses relates to both MH reqs and to app reqs).

Danny >
I agree

Alex >
> service, but still, it is a service that mobile operators provide and 
> this is enough proof for us to acknowledge its need.

> Please see some examples

Thank you very much for these pointers.  This makes it easier to understand the intention.

Is this IPv4 only?

Is this IPv4 only?

 > Sprint -
> _https://www.sprint.com/business/solutions/sprint_enablers/sprint_data
> link_and_static_ip/index.html#.VxC7xSN9480_

Is this IPv4 only?

I am asking the IP version question because address configuration is very different in IPv6 than IPv4.

For example, in IPv6 the network does not assign an address to a host (as in IPv4 is done with context setup), but advertises a prefix to a link and the host forms an address.  In such a context the potential mechanism to achieve static IP addresses is very different - not only the network is in charge but the terminal too.

Moreover, whereas in IPv4 cellular networks the mechanism to achieve static IP address is standardised (NAI, PDP context setup, ppp), in IPv6 there is no such mechanism standardised nor deployed.

Is there an example of deployed static IPv6 addresses in cellular networks? (as the IPv4 example of AT&T, Verizon, Sprint).  That would be very relevant too.

Danny >
Well, to the best of my knowledge, IPv4 is still more popular than IPv6 in the States. But if this service is available for IPv4 today, I believe operators will provide it with IPv6 service once they believe there is a business justification. We do not want to prevent this right?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 18 May 2016 15:32:48 +0200

Danny,

Thank you for the reply.

I agree with most comments.

I appreciate the effort you made to make a common understandable email.

But we may further need to better understand each other by email.  To
that end, we would need to use a common way of citing each other.  There
are many ways that each person believes is the best.  But there is only
one way that is agreed by most.

Le 16/05/2016 à 11:58, Moses, Danny a écrit :
> Hi Alex,
>
>
> Thank you very much for the detailed review and comments. I have
> tried to answer them, but if I was not able to be clear enough, I
> will be happy to discuss this with you.
>
> I am removing parts of the previous exchange so that everyone can
> find the open questions and answers more easily.
>
> Regards, /Danny
>
>
> Alex > Yet, some questions arise:
>
> The apps which don't require a session-lasting IP address can
> obviously work with a session-lasting IP address too.  So some of
> the session-lasting IP addresses can be non-persistent IP addresses?
>
> Danny > True, applications that do not require a session-lasting IP
> address can work correctly with a session-lasting IP address. But in
> that case, the network will invest resources in guaranteeing this
> without any real need and thus, these resources will be wasted.

Intuitively it can appear so: more state in routers maybe needed to
maintain routes to an IP address which moves, rather than simply
changing the IP address.  And that state may look more expensive.

On another hand, it may be that that 'cost' is artificial in the first
place.  Modem connections were first charged on a per-time basis - it
was artificial; now there are flat rates.  Initial 4G subscriptions
plans allowed only for 1Gb 'fair use' - it was artificial; now there is
50Gb 'faire use' for same price as 1Gb only 2 years ago.

Currently, some cellular operators only offer session-lasting IP
addresses (do not offer non-persistent IP addresses).

> From the application side, its traffic may suffer from the treatment
> associated with providing session-lasting characteristics
> (non-optimal routing, encapsulation/decapsulation overhead which
> influences MTU, etc).

Again, this may look so, intuitively speaking.  But I beg to differ.

If one looks at a cellular network from a latency perspective, one has
to imagine the radio access link as very large, and the core network as
very small.  That means that sub-optimal routing and encap/decap
overheads are very small compared to the radio access.

On 4G, latency between the UE and the first IP hop is in the order of 50
milli-seconds, whereas the Ethernet latency (supposedly used in the
wired segment to the first IP hop) is in the order of 1 micro-second.

So, if instead of the optimal routing 1 micro-second the non-optimal
routing is 3 micro-seconds that is very small compared to the radio
access latency.  That can not be considered as additional cost.

> Still, I believe that there will be cases when this is performed.
> One example is in cellular networks that automatically provide
> tunneling and do not support the ability to receive IP address type
> requests from the mobile node.

Right.

> But, if an application requests a session-lasting IP address, and
> the network provides one, it should treat it as such - e.g. provide
> IP continuity guarantee throughout the lifetime of the session. The
> network cannot tell if the address is 'really' using the guarantee
> or not.

I can not agree that an application will require some kind of IP address.

> I did not understand what you mean by 'So some of the
> session-lasting IP addresses can be non-persistent IP addresses?'.
> No, if the network provides a session-lasting IP address, it is
> committed to guarantee it (even if the application does not need the
> service).
>
> Alex > The apps which require a session-lasting IP address wish to
> introduce overhead in the network?
>
> Danny > Apps which require session-lasting IP addresses are apps
> that cannot recover from the event of source IP addresses becoming
> obsolete as a result of the mobile node moving to a LAN with a
> different IP prefix. This is why they request a session-lasting IP
> address. Not because they wish to introduce overhead - this is a by
> product...
>
> Alex > Mobile operators using GTP or PMIP do not provide
> non-persistent IP addresses?
>
> Danny > Mobile operators using GTP or PMIP provide a guarantee that
> the source IP address they allocated to a mobile node will continue
> to exist (and be valid) as long as the mobile node is connected to
> the network (or as long as the DHCP lease condition are meat - if
> DHCP is used). This even a better guarantee than what we defined by
> 'session-lasting' IP address, because the GTP/PMIP source IP address
> is guaranteed regardless of the initiation/end of IP session.

I can not imagine a Mobile operator which will give an address to a
mobile that is not accepted on another access point.  That is the whole
point of 'Mobile' in mobile operator.  Imagine - the end users will have
to stay fixed (dont move), if they started some application.  And there
are many applications out there unaware.  Or one would have to update
all existing applications?

This will _not_ work whenever the user wants to get in a train or car
either (despite having the feeling of being fixed).  Or do you consider
the Mobile operator will equip the trains and the cars as well?

> In our understanding, this extra guarantee is not really needed and
> in the DMM environment where they may be multiple mobility anchors
> might even introduce inefficient routing (which could be avoided in
> the newly introduced scheme).
>
>> source IP address to be valid throughout the time the mobile host
>> is connected to the mobile network. We concluded that mobile hosts
>> do not really require such a guarantee. It is sufficient to require
>> a guarantee of the IP address availability while there is/are an IP
> Danny > In current implementation a source IP address is allocated
> to the mobile host and is valid throughout the connection of the
> mobile host to the network. This is why I use the term 'mobile host'
> in the description that you quoted.
>
> We are introducing an new concept - 'OnDemand' - where each time an
> IP session is created (by an application running on the host), an
> application can request a specific source IP address for that
> session (with specific type). From the network's perspective, this
> address was allocated to a mobile host. This means that at any given
> time, a mobile host might have more than one source IP address
> allocated to in, and different IP sessions initiated by that host (by
> different applications running on that host) may be used in different
> packets being sent/received by it.
>
> I can understand why this is confusing. If this explanation is not
> sufficient, I will be happy to discuss this point with you.

Yes, please clarify whether one has to update all applications in order
to take advantage of this 'ondemand' aspect?

>> more efficient for applications to request a new Session-lasting
>> IP address when launched rather than using an existing one that
>> was allocated to the mobile host in the past.
>
> Danny > Well, they did not use the term 'OnDemand' specifically, but
> they did show that in a distributed mobility anchor scheme, there are
> cases where allocating a new IP address may result in a more optimal
> route of the IP flow compared with using the already-allocated IP
> address. This is because the original IP address is served by one
> mobility anchor (hence all traffic must be routed through it), and
> after the mobile host moves to a new location, traffic may
> possibility be routed via a different mobility anchor which is
> topologically better. Once again, we can further discuss this topic).
>
> Alex > In the environments I work I never saw an application (e.g. a
> browser) to request an IP address.  It is the connection manager
> which deals with address configuration.  This connection manager is
> not in contact with other applications like web browsers.
>
> Danny > That is correct - application do not request IP addresses.
> This is a new concept we are introducing. Application, through the
> Socket interface, can indicate to the TCP/IP stack, the type of
> source IP address they require. The TCP/IP stack, will ether
> associate an existing IP address with that Socket or initiate a
> request to the network for a source IP address of the desired type.

It makes sense in a way: applications featuring 'ondemand' may put less
apparent strain in the network.

However, we need to make sure that all existing applications continue to
work as before even if they dont run 'ondemand'.

>
> Alex >
>> This is due to possible movement of the mobile host to a LAN which
>> is being served by a mobility anchor that is different from the one
>> that was used when the older Session-lasting IP address was
>> assigned to the mobile host. Fixed IP address (no renaming ...):
>> We believe that this is where our original text was the most
>> unclear leading to the confusion on the mailing list and the
>> comments from the flour.
>
>> A Fixed IP address is guaranteed by the network to Always be
>> reachability in addition to IP session continuity, and mobile
>> hosts may register these addresses in DNS infrastructure for name
>> resolution.
>
> A 'fixed' IP address, as much as it can be guaranteed by an operator
> at a premium cost, will not be possible if moving to a more remote
> area: for example, when moving from US to Europe can not maintain
> that fixed IP address even if it is paid a very high price.
>
> Danny > With the appropriate roaming implementation, even this can
> be achieved.

Well, I think that can be a good goal, but I can't see it happening.

The roaming concepts in telecom operators kept evolving in recent years:
acquisitions of networking assets across multiple continents; regulatory
bodies fix budget limits while roaming; billing agreements between
certain countries exist to make look as if at home.  Yet in none of
these is it possible to keep same IP address while moving across large
areas.

Whatever amount of money one pays, one can't just make host-based routes
across the globe - it equates to the price of all Internet altogether.

> But, when moving to an area where no roaming partner exists, you are
> correct. But this sounds to me like a business issue, not technical.

I think it is technical.

I think even when roaming partners exist, some things may appear as if 
at home, but never the IP address is the same.

> Danny > You are correct. Its applications, not mobile hosts...
>
> Alex >
>
> Danny > I agree

  [...]

> For example, in IPv6 the network does not assign an address to a
> host (as in IPv4 is done with context setup), but advertises a prefix
> to a link and the host forms an address.  In such a context the
> potential mechanism to achieve static IP addresses is very different
> - not only the network is in charge but the terminal too.
>
> static IP address is standardised (NAI, PDP context setup, ppp), in
> IPv6 there is no such mechanism standardised nor deployed.
>
> networks? (as the IPv4 example of AT&T, Verizon, Sprint).  That
> would be very relevant too.
>
> Danny > Well, to the best of my knowledge, IPv4 is still more
> popular than IPv6 in the States. But if this service is available for
> IPv4 today, I believe operators will provide it with IPv6 service
> once they believe there is a business justification. We do not want
> to prevent this right?

Right, we dont want to prevent that.

But we dont want to prevent these operators to migrate to IPv6 either, 
simply because IPv4 had the above cited Static IP addresses, whereas 
IPv6 didnt have.

If the referred operators dont talk IPv6 in the first place in their web 
pages, then I think it is not worth talking about them here; moreover - 
it is not worth designing solutions satisfying some need they may (or 
may not) have.  We are a huge distance apart.

Alex

---

From: "Moses, Danny" <[email-masked]>
Date: Thu, 19 May 2016 08:03:07 +0000

Hi Alex,

My replies in this email are marked with 'Danny >>2'.
Regards,
	/Danny

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Wednesday, May 18, 2016 16:33
To: Moses, Danny; [email-masked]
Subject: Re: [DMM] OnDemand draft: 3 address types discussion

Danny,

Thank you for the reply.

But we may further need to better understand each other by email.  To that end, we would need to use a common way of citing each other.  There are many ways that each person believes is the best.  But there is only one way that is agreed by most.

Le 16/05/2016 à 11:58, Moses, Danny a écrit :
> Hi Alex,
>
>
> Thank you very much for the detailed review and comments. I have tried 
> to answer them, but if I was not able to be clear enough, I will be 
> happy to discuss this with you.
>
> I am removing parts of the previous exchange so that everyone can find 
> the open questions and answers more easily.
>
> Regards, /Danny
>
>
> obviously work with a session-lasting IP address too.  So some of the 

Intuitively it can appear so: more state in routers maybe needed to maintain routes to an IP address which moves, rather than simply changing the IP address.  And that state may look more expensive.

On another hand, it may be that that 'cost' is artificial in the first place.  Modem connections were first charged on a per-time basis - it was artificial; now there are flat rates.  Initial 4G subscriptions plans allowed only for 1Gb 'fair use' - it was artificial; now there is 50Gb 'faire use' for same price as 1Gb only 2 years ago.

Currently, some cellular operators only offer session-lasting IP addresses (do not offer non-persistent IP addresses).

Danny >>2
I am not sure I understood your comment here. When I referred to 'cost' I did not mean actual dollars. I was referring to cost of infrastructure, cost in terms of non-optimal routes (which may translate to latency in packet arrival), cost of overhead (encapsulation overhead - for example) etc.

Clearly, all these are saved when there is no need for session-lasting IP guarantee. So if the application does not need this guarantee and the network supports the ability not to provide this guarantee, both sides gain. 

Do you have a concern here? Am I relating to it?
---------------------------------

> associated with providing session-lasting characteristics (non-optimal 
> routing, encapsulation/decapsulation overhead which influences MTU, 
> etc).

If one looks at a cellular network from a latency perspective, one has to imagine the radio access link as very large, and the core network as very small.  That means that sub-optimal routing and encap/decap overheads are very small compared to the radio access.

On 4G, latency between the UE and the first IP hop is in the order of 50 milli-seconds, whereas the Ethernet latency (supposedly used in the wired segment to the first IP hop) is in the order of 1 micro-second.

So, if instead of the optimal routing 1 micro-second the non-optimal routing is 3 micro-seconds that is very small compared to the radio access latency.  That can not be considered as additional cost.

Danny >>2
As I mentioned, there are various costs, not just latency. 
Regarding latency, I am not sure your data will be valid in DMM deployments with multiple mobility anchors. One of the ideas which relates to multiple mobility anchors is to place the anchors close to the base-station (or even co-located in the base-station). This has various advantages (not relevant to OnDemand), but also a disadvantage in terms of routing traffic after a hand-off (since the traffic needs to flow through the original mobility anchor.

But the OnDemand draft does not mandate all future networks to support it. We offer backwards compatibility of working with networks that provide IP address continuity regardless of the application's request. Operators who believe that the cost of providing this guarantee is negligible, may decide not to implement this feature.
-----------------------------------------

Right.

> But, if an application requests a session-lasting IP address, and the 
> network provides one, it should treat it as such - e.g. provide IP 
> continuity guarantee throughout the lifetime of the session. The 
> network cannot tell if the address is 'really' using the guarantee or 
> not.

Danny >>2
I do not understand what you cannot agree to. This whole draft is about applications requesting specific types of IP address. So are you saying that you cannot agree to the OnDemand concept?
--------------------------------

> I did not understand what you mean by 'So some of the session-lasting 
> IP addresses can be non-persistent IP addresses?'.
> Danny > Apps which require session-lasting IP addresses are apps that 
> cannot recover from the event of source IP addresses becoming obsolete 
> as a result of the mobile node moving to a LAN with a different IP 
> prefix. This is why they request a session-lasting IP address. Not 
> because they wish to introduce overhead - this is a by product...
>
> the source IP address they allocated to a mobile node will continue to 
> exist (and be valid) as long as the mobile node is connected to the 
> network (or as long as the DHCP lease condition are meat - if DHCP is 
> used). This even a better guarantee than what we defined by 

I can not imagine a Mobile operator which will give an address to a mobile that is not accepted on another access point.  That is the whole point of 'Mobile' in mobile operator.  Imagine - the end users will have to stay fixed (dont move), if they started some application.  And there are many applications out there unaware.  Or one would have to update all existing applications?

This will _not_ work whenever the user wants to get in a train or car either (despite having the feeling of being fixed).  Or do you consider the Mobile operator will equip the trains and the cars as well?

Danny >>2
The draft does not say that the end user cannot be mobile. It indicates that there are more and more applications that do not break when the source IP address they are using  is obsolete. They simply re-open the Socket and use the new source IP address. So for these types of applications, the session-lasting guarantee is redundant (even when the user is mobile).
--------------------------------------------

> In our understanding, this extra guarantee is not really needed and in 
> the DMM environment where they may be multiple mobility anchors might 
> even introduce inefficient routing (which could be avoided in the 
> newly introduced scheme).
>
> Danny > In current implementation a source IP address is allocated to 
> the mobile host and is valid throughout the connection of the mobile 
> host to the network. This is why I use the term 'mobile host'
> We are introducing an new concept - 'OnDemand' - where each time an IP 
> session is created (by an application running on the host), an 
> application can request a specific source IP address for that session 
> (with specific type). From the network's perspective, this address was 
> allocated to a mobile host. This means that at any given time, a 
> mobile host might have more than one source IP address allocated to 
> in, and different IP sessions initiated by that host (by different 
> applications running on that host) may be used in different packets 
> being sent/received by it.
>

Yes, please clarify whether one has to update all applications in order to take advantage of this 'ondemand' aspect?

Danny >>2
Yes. If an applications wish to request a specific type of source IP address, they have to use the new flags we are specifying in the Socket interface
-----------------------------

>> efficient for applications to request a new Session-lasting IP 
> after the mobile host moves to a new location, traffic may possibility 
> be routed via a different mobility anchor which is topologically 
> better. Once again, we can further discuss this topic).
> browser) to request an IP address.  It is the connection manager which 
> deals with address configuration.  This connection manager is not in 
> contact with other applications like web browsers.
>
> Socket interface, can indicate to the TCP/IP stack, the type of source 
> IP address they require. The TCP/IP stack, will ether associate an 
> existing IP address with that Socket or initiate a request to the 
> network for a source IP address of the desired type.

It makes sense in a way: applications featuring 'ondemand' may put less apparent strain in the network.

However, we need to make sure that all existing applications continue to work as before even if they dont run 'ondemand'.

Danny >>2
That is correct. The draft has a chapter on backwards compatibility. 
------------------------------------------

>> the mobile host. Fixed IP address (no renaming ...):
>> leading to the confusion on the mailing list and the comments from 
>> the flour.
>
>> for servers, VPNs , secured content and other applications.
> area: for example, when moving from US to Europe can not maintain that 
> fixed IP address even if it is paid a very high price.
>
> Danny > With the appropriate roaming implementation, even this can be 
> achieved.

The roaming concepts in telecom operators kept evolving in recent years:
acquisitions of networking assets across multiple continents; regulatory bodies fix budget limits while roaming; billing agreements between certain countries exist to make look as if at home.  Yet in none of these is it possible to keep same IP address while moving across large areas.

Whatever amount of money one pays, one can't just make host-based routes across the globe - it equates to the price of all Internet altogether.

I think it is technical.

I think even when roaming partners exist, some things may appear as if at home, but never the IP address is the same.

Danny >>2
OK. Let's agree to disagree on whether or not Fixed IP addresses can be supported in roaming scenarios.
Does that impact the whole concept? I do not think so...
--------------------------------------------

  [...]

> mechanism to achieve static IP addresses is very different
> networks? (as the IPv4 example of AT&T, Verizon, Sprint).  That would 
> be very relevant too.
>
> Danny > Well, to the best of my knowledge, IPv4 is still more popular 
> than IPv6 in the States. But if this service is available for
> IPv4 today, I believe operators will provide it with IPv6 service once 
> they believe there is a business justification. We do not want to 
> prevent this right?

But we dont want to prevent these operators to migrate to IPv6 either, simply because IPv4 had the above cited Static IP addresses, whereas
IPv6 didnt have.

If the referred operators dont talk IPv6 in the first place in their web pages, then I think it is not worth talking about them here; moreover - it is not worth designing solutions satisfying some need they may (or may not) have.  We are a huge distance apart.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 19 May 2016 10:33:26 +0200

[...]

> Danny >>2 I am not sure I understood your comment here. When I
> referred to 'cost' I did not mean actual dollars. I was referring to
>  cost of infrastructure, cost in terms of non-optimal routes (which
> may translate to latency in packet arrival), cost of overhead
> (encapsulation overhead - for example) etc.

Hi Danny,

These costs - infra, non-optimal routes, latency in packet arrival - are
two: memory-CPU costs in the infra, and latency costs.

The memory and CPU cost in the infra, induced by triangular routing, can
be characterized by the memory size and CPU cycles.  In triangular
routing there is one more entry in the routing tables in memory at a 3rd
point (instead of just at 2 points).  The CPU cycles - I dont know. How
much is it?

The latency cost: again, as I explained previously - it is negligible -
it is 3 micro-seconds in triangular routing (compared to 2 micro-seconds
w/o triangular routing), when the UE experiences a first hop of 50ms.

The encap/decap costs: there is memory, CPU and on-the wire costs.  What
is the mem-CPU cost?

On the wire cost of encap/decap is very low: encap/decap is about
40bytes of additional header compared to 1200bytes which is the minimal
MTU of IPv6.

> Clearly, all these are saved when there is no need for
> session-lasting IP guarantee.

YEs, but is it worth the effort?  Or is it just like in flat-rate and
'fair use' concepts where we should not worry about the cost, but worry
about the growth.

> So if the application does not need this guarantee and the network
> supports the ability not to provide this guarantee, both sides gain.

If we worry about these costs - then yes.

> Do you have a concern here? Am I relating to it?

YEs, the concern is how much do we gain by modifying the network too 
_not_ provide the currently provided stable addresses?

[...]

> Danny >>2 As I mentioned, there are various costs, not just latency.
>  Regarding latency, I am not sure your data will be valid in DMM
> deployments with multiple mobility anchors. One of the ideas which
> relates to multiple mobility anchors is to place the anchors close to
> the base-station (or even co-located in the base-station). This has
> various advantages (not relevant to OnDemand), but also a
> disadvantage in terms of routing traffic after a hand-off (since the
>  traffic needs to flow through the original mobility anchor.

I dont understand: if we place a mobility anchor closer to the base 
station, the traffic after hand-off will no longer flow through the 
original mobility anchor, right?

> But the OnDemand draft does not mandate all future networks to
> support it. We offer backwards compatibility of working with networks
> that provide IP address continuity regardless of the application's
> request. Operators who believe that the cost of providing this
> guarantee is negligible, may decide not to implement this feature.

A-ha, but it's not related to our discussion.

[...]

> Danny >>2 I do not understand what you cannot agree to. This whole
> draft is about applications requesting specific types of IP address.
>  So are you saying that you cannot agree to the OnDemand concept?

If the OnDemand concept could be applied to specific connectivity 
managers - then I could agree with the concept.

I dont agree that any other application needs to require some particular 
kind of application.

The existing base is that of applications which consider that address to 
be stable and fixed.  This is the default and should continue.

Improved applications may develop a relationship with a new Connectivity 
Manager which may in turn request address kinds.
[...]

> Danny >>2 The draft does not say that the end user cannot be mobile.
>  It indicates that there are more and more applications that do not
> break when the source IP address they are using  is obsolete. They
> simply re-open the Socket and use the new source IP address. So for
> these types of applications, the session-lasting guarantee is
> redundant (even when the user is mobile).

When you say "more and more applications" do you mean smartphone 
applications?

In my setting, we dont consider smartphones, but multiple bigger 
computers connected to a cellular link through a Mobile Router.  Such 
computers run different kinds of apps than the typical *-store-based apps.

[...]
> Danny >>2 OK. Let's agree to disagree on whether or not Fixed IP
> addresses can be supported in roaming scenarios. Does that impact the
> whole concept? I do not think so...

Right, it doesnt impact the whole concept.  It just modifies it: on a 
large scale, it's impossible to provide a fixed IP address - as such 
dont request one if it's on a large scale.

Alex

>> requirements, or only mobile host reqs, or both but everywhere
>> (i.e. each of the 3 types of addresses relates to both MH reqs and
>>  to app reqs).
>>
>> Danny > I agree
>>
>> Alex >
>> host (as in IPv4 is done with context setup), but advertises a
>> prefix to a link and the host forms an address.  In such a context
>>  the potential mechanism to achieve static IP addresses is very
>> different - not only the network is in charge but the terminal
>> too.
>>
>> Moreover, whereas in IPv4 cellular networks the mechanism to
>> achieve static IP address is standardised (NAI, PDP context setup,
>>  ppp), in IPv6 there is no such mechanism standardised nor
>> deployed.
>>
>> popular than IPv6 in the States. But if this service is available
>> for IPv4 today, I believe operators will provide it with IPv6
>> service once they believe there is a business justification. We do
>>  not want to prevent this right?
>
> But we dont want to prevent these operators to migrate to IPv6
> either, simply because IPv4 had the above cited Static IP addresses,
>  whereas IPv6 didnt have.
>
> If the referred operators dont talk IPv6 in the first place in their
>  web pages, then I think it is not worth talking about them here;
> moreover - it is not worth designing solutions satisfying some need
> they may (or may not) have.  We are a huge distance apart.
>
> Alex
>
> This e-mail and any attachments may contain confidential material
> for the sole use of the intended recipient(s). Any review or
> distribution by others is strictly prohibited. If you are not the
> intended recipient, please contact the sender and delete all copies.
>
>

---

From: "Moses, Danny" <[email-masked]>
Date: Mon, 23 May 2016 09:50:15 +0000

Hi,

My newest answers are marked: Danny>>3

Regards,
	/Danny

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Thursday, May 19, 2016 11:33
To: Moses, Danny; [email-masked]
Subject: Re: [DMM] OnDemand draft: 3 address types discussion

[...]

> cost of infrastructure, cost in terms of non-optimal routes (which may 
> translate to latency in packet arrival), cost of overhead 

Hi Danny,

The memory and CPU cost in the infra, induced by triangular routing, can be characterized by the memory size and CPU cycles.  In triangular routing there is one more entry in the routing tables in memory at a 3rd point (instead of just at 2 points).  The CPU cycles - I dont know. How much is it?

The latency cost: again, as I explained previously - it is negligible - it is 3 micro-seconds in triangular routing (compared to 2 micro-seconds w/o triangular routing), when the UE experiences a first hop of 50ms.

The encap/decap costs: there is memory, CPU and on-the wire costs.  What is the mem-CPU cost?

On the wire cost of encap/decap is very low: encap/decap is about 40bytes of additional header compared to 1200bytes which is the minimal MTU of IPv6.

> Clearly, all these are saved when there is no need for session-lasting 
> IP guarantee.

YEs, but is it worth the effort?  Or is it just like in flat-rate and 'fair use' concepts where we should not worry about the cost, but worry about the growth.

> Do you have a concern here? Am I relating to it?

YEs, the concern is how much do we gain by modifying the network too _not_ provide the currently provided stable addresses?
Danny>>3
Well, you are showing some costs, but I am not sure you covered all of them. Nevertheless, there are quite a few people that think that the investment is worth the savings in latency, CPU and memory, especially with the increasing demands for resource in the future 5G installations. Our intent is to prepare the future access networks for the growing demand not just by increasing the pure bandwidth of the wire (or wireless medium), but also by improving other aspects (as described).
Clearly, there will never be consensus as to the appropriate features and we do not expect all operators to support them at once. But, unless better and competing ideas are introduced, we think they will gradually be used. Remember, even IPv4 is still very common, although IPv6 has been released ages ago.
--------------------------------------

[...]

> various advantages (not relevant to OnDemand), but also a disadvantage 
> in terms of routing traffic after a hand-off (since the  traffic needs 
> to flow through the original mobility anchor.

I dont understand: if we place a mobility anchor closer to the base station, the traffic after hand-off will no longer flow through the original mobility anchor, right?
Danny>>3
This is not correct. Packets generated by the Sockets that were opened before the hand-off must be routed through the original mobility anchor (hence the triangular routing you mentioned previously.  Packets generated by Sockets opened after the hand-off will be routed via the new mobility anchor (if the mobile host is triggered to request a new session-lasting IP address after the hand-off). 
----------------------------------------------------

> But the OnDemand draft does not mandate all future networks to support 
> it. We offer backwards compatibility of working with networks that 
> provide IP address continuity regardless of the application's request. 
> Operators who believe that the cost of providing this guarantee is 
> negligible, may decide not to implement this feature.

[...]

>  So are you saying that you cannot agree to the OnDemand concept?

If the OnDemand concept could be applied to specific connectivity managers - then I could agree with the concept.

I dont agree that any other application needs to require some particular kind of application.

The existing base is that of applications which consider that address to be stable and fixed.  This is the default and should continue.

Improved applications may develop a relationship with a new Connectivity Manager which may in turn request address kinds.

Danny>>3
The 'mobility manager' is not well defined so It is difficult for me to related to it.
The 'OnDemand' concept assumes that - (a) not all applications require the session-lasting service and (b) the 'demand' is performed through the Socket interface which is and interface for application.
So, yes, we count of applications to request the IP address type. Applications are the only entity who knows if it requires session-lasting IP addresses or can handle source IP address changes without breaking.

I did not understand what you do not agree to. You might have a typo in that sentence.
--------------------------------------
[...]

> redundant (even when the user is mobile).

When you say "more and more applications" do you mean smartphone applications?
Danny>>3
Coould be smartphone applications but also others. For example, any application that performs short data exchanges in long periods of time, could recover from a source IP address change without breaking.
---------------------------

In my setting, we dont consider smartphones, but multiple bigger computers connected to a cellular link through a Mobile Router.  Such computers run different kinds of apps than the typical *-store-based apps.

[...]
> whole concept? I do not think so...

Right, it doesnt impact the whole concept.  It just modifies it: on a large scale, it's impossible to provide a fixed IP address - as such dont request one if it's on a large scale.

Alex

>> than IPv6 in the States. But if this service is available for IPv4 
>> today, I believe operators will provide it with IPv6 service once