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

["Noll, Kevin" <kevin.noll at twcable.com>]

Hesham,

I don't think I was assuming kernel-space or user-space. I *think* I was
approaching this from how I have seen most implementations. It seems
pretty typical that the connection manager is a user-space application,
but the data-card drivers are OS-level. For example, in Windows a 3G
data-card typically is installed as a RAS device and WiFi cards show up
as NDIS.

I don't think any solution *must* hold to this model. Thanks, though,
for calling out what may be an unknown assumption on my part.

Agreed, carriers manage mobility on both sides and at multiple layers.
From my point of view (at least for this discussion) I only care about
L3 and assume that any lower-layer mobility is hidden from me. On the
other hand, I think it is important, if not necessary, that L1/L2
information be available to L3 and above in order to make HO functions
more robust.

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. Of course, there are implications on memory, CPU, etc.
so my all or nothing approach is probably not a very practical one. 

--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.