Hi,
My newest answers are marked: Danny>>3
Regards,
/Danny
-----Original Message-----
From: Alexandre Petrescu [mailto:[email protected]]
Sent: Thursday, May 19, 2016 11:33
To: Moses, Danny; [email protected]
Subject: Re: [DMM] OnDemand draft: 3 address types discussion
[...]
> 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>>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.
--------------------------------------
[...]
> 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?
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.
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>>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.
--------------------------------------
[...]
> 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?
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.
[...]
> 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.
>
>
---------------------------------------------------------------------
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
