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
--------------- Text removed from previous exchange-----------------
--------------------------------------------------------------------------------
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).
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 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(?)
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?
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.
Well, I wonder about this.
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.
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
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.
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.
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
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
