(keitai-l) Re: Apache authentication on handsets

From: Curt Sampson <cjs_at_cynic.net>
Date: 12/14/01
Message-ID: <Pine.NEB.4.33.0112141930150.1039-100000@angelic.cynic.net>
On Thu, 13 Dec 2001, cfb wrote:

> I guess my point was that whatever MTA the handsets use, the MTA
> connections are hidden behind the same gateways that handle http
> traffic....

I just don't see what's wrong with this. Or maybe I don't understand
what exactly you think is being done wrong.

> Do you know an ISP that *doesn't* offer access using globally reachable
> IP address space?  DoCoMo is the only one that I know of.

I would imagine that most any "ISP" that a) provides limited access
to only two specific services, b) restricts use to a single specific
type of device (which is not a general purpose computer), and c)
does not provide access via IP, would also not bother assinging
routable addresses, or even non-routable ones.

I mean, these phones don't do IP! If you assigned them addresses,
they'd be useless, because you can't put the devices on the net!

> > [cjs's details about efficiency deleted.]

> At 9600bps we're not talking about imode...

Uh...what? Since when is imode anything but 9600 bps to the phone?
Yes, I know it's going up to 28kbps or so in the future, but we're
not there yet, and even that is not exactly blazing speed.

> With regard to
> latency, it might be a good idea to remember we're talking
> digital transport and that the latency is already pretty low....

This is just wrong. On a 9600 bps link, if you're running IP, the
latency is *always* high (in the many hundreds of ms. to send an
HTTP request and receive a zero-length response), and that's just
the nature of the connection. Digital or analogue, it doesn't
matter. If you want to dispute this, first work out what packets
are being sent and how many bytes are in each packet, and work
though the entire TCP transaction (remembering slow start). Assume,
say, 25 ms. latency from the Internet, and latency due only to
transmission-time on the 9600 bps link. Then you'll see what I
mean.

> By using a proprietary transport (which I would strongly question
> to begin with), the edge devices are denied the benefit of an
> Internetworking Protocol... which can potentially increase the
> amount of coding that must be done at the gateway or edge device
> (Java) level, which reduces the level in independent innovation
> and increases the amount of time it takes for developers to deploy
> ideas (IMHO).

I agree.

> To me, this outweighs the potential 15% performance
> gain.

The performance gain is going to be way, way more than 15%. I'd
estimate it at at least 200%, mostly due to a huge reduction in
the amount of data transferred, but also (one hopes) due to a
protocol more suited to the nature of a 9600 bps wireless link than
TCP is.

> At any rate, there's no reason that DoCoMo could not have had the
> same amount of control using something like Mobile IP or globally
> reachable IP addresses.... and, in fact, I can think of a lot of
> reasons that they might have to go back and re-engineer, adding
> outside reachability to the edge devices.

That's not re-engineering; that's building a new network! And in
fact, that would be just what a PPP connection over packet-mode
PHS is, which docomo is certainly capable of offering.

cjs
-- 
Curt Sampson  <cjs_at_cynic.net>   +81 90 7737 2974   http://www.netbsd.org
    Don't you know, in this new Dark Age, we're all light.  --XTC
Received on Fri Dec 14 12:55:48 2001