[...]
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.
[...]
I can not agree that an application will require some kind of IP
address.
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
--------------------------------------------
Alex >
Clearly, most mobile hosts do not require Fixed IP
Again: _mobile hosts_ require? Or apps require?
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 >
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.
[...]
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?
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
---------------------------------------------------------------------
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.
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
