Re: [netlmm] [netext] [MEXT] NEXTEXT2: first draft of the bof description

[Hesham Soliman <hesham at elevatemobile.com>]

> Also, I tend to think that network-based mobility (e.g. PMIP6) should be
> network-based and not place requirements on the MN. Similarly, if you
> are going to make a requirement on the MN, you might as well go all-in
> and make it CMIP.

=> I agree with this. I think it's a practical approach to do that, at least
from a requirements point of view. I personally don't believe you can use
PMIP to support multihoming, flow movements ....etc but as far as
requirements go this is sensible because it's sticking for the reasons with
going to PMIP in the first place.

 Of course, there are implications on memory, CPU, etc.
> so my all or nothing approach is probably not a very practical one.

=> I wouldn't worry about memory/CPU requirements for MIP with today's 3G
devices, by the time it's implemented it will be an insignificant part of
the memory on a phone, not to mention a PC.

Hesham

> 
> --kan--
> --
> Kevin A. Noll
> 
> 
> -----Original Message-----
> From: Hesham Soliman [mailto:hesham at elevatemobile.com]
> Sent: Wednesday, July 01, 2009 12:26 PM
> To: Noll, Kevin; netext at ietf.org; netlmm at ietf.org
> Subject: Re: [netext] [netlmm] [MEXT] NEXTEXT2: first draft of the bof
> description
> 
> Kevin, 
> 
> Thanks for the input. I understand where you're coming from and I have
> two
> small comments to make.
> 
> First I think you're assuming that mobility support for the multihoming
> scenario we're discussing must be done in the kernel. This is not the
> case
> at all. Things can be done in user space as an add-on application.
> 
> Second, you made this comment:
> 
>> 4. At least some carriers prefer to manage mobility inside the network
>> rather than on the customer device. This is something that we are
>> constantly discussing internal to our organization, with vendors, and
>> with other operators.
> 
> => To be precise, all carriers manage mobility from both the network and
> host sides. It's just not L3 mobility. So the question should be whether
> it
> is acceptable to manage L3 mobility on both sides as well. And there is
> pretty good reasons for doing that, especially that most mobile devices
> today have multiple interfaces to different technologies, which never
> happened before. 
> 
> Hesham
> 
> 
> On 1/07/09 11:52 PM, "Noll, Kevin" <kevin.noll at twcable.com> wrote:
> 
>> I've been lurking here for a while watching the conversation. Please
>> accept my apologies for dropping in unexpectedly, but I thought I
> might
>> give at least one operator's viewpoint.
>> 
>> You are correct that most data cards being sold today require you to
>> install the carrier's software. This software typically contains a
>> connection manager and the OS drivers required to operate the data
> card.
>> Technically speaking, the data cards that I have worked with do not
> all
>> *require* the connection manager to operate, though it varies from
> card
>> to card. Obviously, though, they *do* need the drivers.
>> 
>> What we saw with WiFi was a technology that began as an add-on to our
>> computing devices (laptops, etc.). WiFi grew, matured, and became so
>> widely accepted that operating systems began to ship with native
>> drivers, the add-on device became integrated into the computing
> devices
>> and we no longer needed to install 3rd-party drivers or connection
>> software.
>> 
>> As a network provider/operator, we like this model because it is very
>> expensive to write and maintain the connection software and drivers
> and
>> keep the user's device up to date. Adding a mobility stack to the
>> software being installed adds significantly to this cost. We are
> seeing
>> the cost come down, but there's still the issue of configuration and
>> what-not.
>> 
>> We expect to see open networks and technologies like WiMAX (and
> possibly
>> LTE) change the traditional cellular data-card model to one that is
> more
>> similar to WiFi, hopefully driving down the cost of the software and
>> moving the software development tasks out of the operator and into the
>> OS vendor community.
>> 
>> This said, I think it would be a mistake to make any assumptions on
>> either of the two points mentioned below.
>> 
>> 1. In the future the carrier may not deliver software with the data
>> card, so it's probably a bad assumption to say that the carrier would
>> simply deliver a mobility stack with the device.
>> 
>> 2. It's probably a good assumption to say that devices will eventually
>> have native mobility stacks. We are already seeing this development in
>> mainstream operating systems. This is similar to the evolution of
> WiFi.
>> 
>> 3. It's probably not a good assumption to say that *all* devices will
>> have the perfect combination of native support or carrier support.
>> 
>> 4. At least some carriers prefer to manage mobility inside the network
>> rather than on the customer device. This is something that we are
>> constantly discussing internal to our organization, with vendors, and
>> with other operators.
>> 
>> Based on this, the case for extending the functionality of PMIP6 is
>> pretty strong, at least in my opinion.
>> 
>> On the other hand, we will also continue following the development of
>> native stacks and evaluate when and how best to use them in our
> product
>> offerings. Similarly, we will continue to evaluate whether or not we
>> need to deliver a mobility stack with our data card software.
>> 
>> Thanks!
>> 
>> --kan--
>> --
>> Kevin A. Noll
>> 
>> 
>> 
>> P Go Green! Print this email only when necessary. Thank you for
> helping Time
>> Warner Cable be environmentally responsible.
>>  
>>  
>> -----Original Message-----
>> From: netlmm-bounces at ietf.org [mailto:netlmm-bounces at ietf.org] On
> Behalf
>> Of Hesham Soliman
>> Sent: Tuesday, June 30, 2009 11:59 PM
>> To: Basavaraj.Patil at nokia.com; marcelo at it.uc3m.es
>> Cc: netext at ietf.org; netlmm at ietf.org
>> Subject: Re: [netlmm] [MEXT] [netext] NEXTEXT2: first draft of the bof
>> description
>> 
>> 
>> Hi Raj, 
>> 
>> I had a brief offline chat with Julien and thought that I could refine
>> my
>> suggestion a bit more to make the point clearer. My point is that
> there
>> are
>> currently two slightly different points being made about the
> requirement
>> on
>> host involvement 1) no SW on the host and the more nuanced 2) no
>> protocol
>> support on the host. I won't even get into the reasons for point 2)
>> above
>> and I'll let the people who raise it provide those reasons, I can't
>> figure
>> out any technical reasons there.
>> 
>> Anyway, my point is that 1) above is not an issue today because it
>> already
>> happens on a very large scale, so requiring it for a specific feature
>> like
>> multihoming is hardly a leap. I can imagine ads for "download your
>> wireless
>> optimiser from wwww.operator.com and save money" (ok not very
> creative).
>> The subtle difference between 1) and 2) is IMO a moot point anyway
>> because
>> 2) simply says that operators don't want protocol support in the
>> network,
>> but that support already exists in the form of PMIP and if you have
> PMIP
>> you
>> have MIP. So, both motivations seem to be on shaky ground.
>> And yes, you can of course integrate 3G modems in computers, but you
> can
>> also integrate mobility code in the same computers with the 3G
> support.
>> The
>> SW that is provided with the modems is not only connection SW it
>> actually
>> provides a number of features (e.g. Receiving SMS, account
> information,
>> email ....etc) so it's a clear move by operators to be present on
> those
>> machines. I don't think it's anything like WLAN connctions SW.
>> 
>> Of course it's worth mentioning that the elephant in the room is the
>> binary
>> requirement on host support of protocols. We need to have a yes/no
>> answer as
>> to whether there is a requirement to NOT have protocol support in the
>> host.
>> At the moment this is being kept very vague.
>> 
>> Hesham
>> 
>>>> => No one I know can get a 3G data card to access the Internet from
>> their PC
>>>> without having to install a piece of software  on their PC to make
> it
>> work.
>>>> So I think your assumption that the operator cannot mandate software
>> on the
>>>> host is questionable, because they already do (unfortunately).
>>> 
>>> The situation that you describe above was the same when 802.11 first
>> rolled
>>> around as well.
>>> You had to install a piece of software that came with the PC card.
> But
>> that
>>> has changed with
>>> wifi now being an integral part of the notebook computers.
>>> And I think you could expect 3G chipsets and access built-in as well
>> in due
>>> course of time. At least I know of a few
>>> operators in the US (as well as notebook manufacturers) who offer
> such
>>> net/notebook computers,
>>> i.e with integrated 3G access. I do not know what additional sw is
>> loaded on
>>> these but at least the end user
>>> is not installing anything else.
>>> Does it imply that such hosts will include the software that would
>> enable host
>>> mobility? Its an open question (i.e unknown)
>>> and will depend largely on operator choices and vendors.
>>> 
>>> -Raj
>>> 
>>>> Hesham
>>> 
>>> _______________________________________________
>>> netlmm mailing list
>>> netlmm at ietf.org
>>> https://www.ietf.org/mailman/listinfo/netlmm
>> 
>> 
>> _______________________________________________
>> netlmm mailing list
>> netlmm at ietf.org
>> https://www.ietf.org/mailman/listinfo/netlmm
>> This E-mail and any of its attachments may contain Time Warner
>> Cable proprietary information, which is privileged, confidential,
>> or subject to copyright belonging to Time Warner Cable. This E-mail
>> is intended solely for the use of the individual or entity to which
>> it is addressed. If you are not the intended recipient of this
>> E-mail, you are hereby notified that any dissemination,
>> distribution, copying, or action taken in relation to the contents
>> of and attachments to this E-mail is strictly prohibited and may be
>> unlawful. If you have received this E-mail in error, please notify
>> the sender immediately and permanently delete the original and any
>> copy of this E-mail and any printout.
>> _______________________________________________
>> netext mailing list
>> netext at ietf.org
>> https://www.ietf.org/mailman/listinfo/netext
> 
> 
> This E-mail and any of its attachments may contain Time Warner
> Cable proprietary information, which is privileged, confidential,
> or subject to copyright belonging to Time Warner Cable. This E-mail
> is intended solely for the use of the individual or entity to which
> it is addressed. If you are not the intended recipient of this
> E-mail, you are hereby notified that any dissemination,
> distribution, copying, or action taken in relation to the contents
> of and attachments to this E-mail is strictly prohibited and may be
> unlawful. If you have received this E-mail in error, please notify
> the sender immediately and permanently delete the original and any
> copy of this E-mail and any printout.
> 
> _______________________________________________
> netlmm mailing list
> netlmm at ietf.org
> https://www.ietf.org/mailman/listinfo/netlmm