Subject: Re: [MOBILE-IP] AAA functionality

From: Patrice Calhoun <[email-masked]>
Date: Fri, 7 Jan 2000 07:25:26 -0800

Phil,

My understanding, from TIA meetings, is that one of the main reasons behind
not going with co-located MN is simply the header overhead over the air
network.

If spectrum wasn't an issue, I think that most people would agree with you.
Perhaps the day that the government stops treating spectrum like property,
we may get to this point.

PatC

>>It is also an issue for the carrier that wants to be more then a simple
>>"pipe" to transport data over.  I do agree that you are entitled to your
>
>Ah, here we reach the crux of the issue. Speaking as a potential user
>of your service, an IP "pipe" is all I want from you, and it's all I'm
>willing to pay for.
>
>And it's not just me. I know I speak for many prospective users (the
>ones who understand the issues, anyway) and for those who conceived
>the Internet architecture. Go read the classic paper by Saltzer, Reed
>& Clark, "End-to-End Arguments in System Design"
>(http://people.qualcomm.com/karn/library.html).
>
>This one paper is so fundamental that I've often thought prospective
>IETFers (especially those affiliated with telcos) should be required
>to read it and pass a test before they can participate in any IETF
>working group. :-)
>
>Unfortunately, many carriers (not just Sprint) see no glamor in being
>pipe providers, even though they can make plenty of money if they do
>it well and at reasonable cost. It's a widespread problem that also
>afflicts cable modem networks, for example. Fortunately, my own cable
>modem provider is proving themselves so incompetent at operating all
>these superfluous network functions that they're being forced to
>eliminate them just to keep the packets flowing.
>
>Phil

---

From: Mikael Latvala <[email-masked]>
Date: Fri, 7 Jan 2000 18:10:49 +0200

Pat,

> we may get to this point.

I agree with Phil; spectrum is hardly the issue here. Using the
compression principles explained in rfc1144 minimal encapsulation for
example would add only 2 bytes (header checksum for the minimal
forwarding header) to the total size of the compressed header. Same
should be the case also with rfc2003.

/Mikael

---

From: Gerald Maguire <[email-masked]>
Date: Fri, 7 Jan 2000 18:55:52 +0100

Not only do I agree with Phil, but I want to point out that if
efficient spectrum usage is important, then it is all the _more_ reason
to use packets -- since you can now do VOIP and get far more efficient
usage of the channel and you can also elimiate 1/2 the processing
currently done at the basestations -- since you no longer need to do
voice transcoding in the access network (only at the points where this
traffic has to go into the legacy voice networks).

Additionally, by simply supporting packet traffic and doing the
encoding/decoding only in the end-points, it become much easier to
introduce new CODECs which are more efficient or in the case of some
languages more suitable. In the current systems the introduction of
half-rate voice codecs takes a very long time. In certain vendors
basestations the signal processor can not be remotely reprogrammed
(i.e., their is no path from the BSC to the code memory of the signal
processor). Hence to change this code requires a visit to each
basestation. Here is another good example of where an IP network
attached device would be much better, since it is more likely that the
system would be remotely programmable.

Another reason that telecom people should read the "End-to-End
Arguments in System Design" by Jerome H. Saltzer,
David P. Reed, and David D. Clark -- is so that they would stop doing
foolish things like the interleaving that is done in GPRS -- which
both increases the latency and increases the probability of damaging
more than one packet.

Over the last several years a number of theses have shown that the
best thing (in terms of throughput and overall latency) that can be
done with the low level ARQ mechanisms in DECT, GSM, ... is to turn
them off!

Chip

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 7 Jan 2000 10:59:15 -0800

> not going with co-located MN is simply the header overhead over the air

Have they've looked at RFC 2507 and friends?
(There are some issues with packet loss which hopefully a future robhc
working group will address.)

> we may get to this point.

I think physics get in the way. The available spectrum between a sender
and receiver is quite finite and always will be.

Wired bandwith don't have such physical limitations.

   Erik

---

From: Phil Karn <[email-masked]>
Date: Fri, 7 Jan 2000 11:07:29 -0800

>not going with co-located MN is simply the header overhead over the air

Remember the old saying, premature optimization is the root of all
evil.  As I pointed out in my message, header overhead is a red
herring here.

Phil