Handling multiple connections

[Andreas Kostyrka]

Sorry for the long reply time.

Executive summary:
-) IMHO, MMS+WAP despite everything one might think, do have uses, and
basically all phones do support. Actually WAP is an unloved but still
used platform for all kinds of stuff.

-) using multiple APNs (and that basically implies concurrent
connections) are needed, because some WAP services (like payment
services) work only via the internal network of the network provider.

-) Yes, your implementation suggestions are certainly better than my
proposal.

* Harald Welte <laforge at openmoko.org> [070429 09:23]:
> On Sat, Apr 28, 2007 at 08:48:26PM +0200, Andreas Kostyrka wrote:
> 
> > Just wondering, how do we currently plan to handle multiple data
> > connections. I've got the impression that this hasn't been given much
> > of a thought.
> 
> this is more or less true, at least that thought is under flux and will
> certainly not be documented before there is any code, leading to more
> vaporware ;)
Good idea. The hardware feels already vapor-like to many people. ;)

> 
> We seriously have tons of more important issues right now.  As soon as
> the higher priority issues have been implemented, we can always think of
> more advanced features and look on their implementation.
> 
> > a) multiple APNs: Internet, MMS, other apps (guess we won't get a
> >    blackberry client that fast, but still it might happen)
> 
> well, so far this is not on our list of requirements.  so far, we do not
> intend to support MMS or WAP, e.g.

Some thoughts:

*) Both features (WAP/MMS) are standard features of a GSM phone. The
only phones that come to mind that don't have these are phones
designed especially for "people that don't want the complexity, that
want a phone that allows them to talk". No idea how the market
perception will be if Openmoko misses such features.

*) There are markets where MMS are at least partially sucessful.
Receiving MMS is a standard feature, worse, people expect
(herearounds, and well, young people) that one can read MMS. And are
incredibly offended when one ignores them. (And yes, my Treo that I
used at that time did not receive MMS.)

*) I can understand about WAP, but as much it pains me, there 
are applications for this <censormode> %$§%$"$§ </censormode>.
E.g.: http://www.bahn.de/p/view/planen/reiseplanung/mobileservices/faq_handy_ticket.shtml
Mobile ticketing for the German railways. Btw, it needs both MMS and
WAP.

*) Some network operators like to make extra cash by selling
"multimedia" like ringtones. These usually are managed via WAP too.

Just some thoughts.

> 
> > b) VPNs.
> 
> how does that related to a more or less physical connection?  Also,
> there are many technologies (openvpn, ipsec, vtun, cipe, to name a few)
> and they all have their own properties and ideas on how to express
> policy

> 
> > c) CSD dialup connections.
> 
> true.  
> 
> What I think is actually more important and missing from your list :
> 
> d) bluetooth BNEP 
> 
> e) usb ethernet emulation

Yes, I was thinking more about the framework/software implications.

The observations I wanted to mention:

*) mobile device != stationarly TCP/IP host.
*) concurrent different paths are needed.

Just a scenario:

I've been text chatting while sitting in the subway, and somebody
mentions an URL I want to visit. Now I want to look up that URL.
Luckily, I just arrived home, so I have an accesspoint (be it USB,
Bluetooth or WLAN) for high speed access.

Now if the device does not support concurrent paths, either I need to
surf the web via a GPRS (4-5KB/s connection), or I need to interrupt
my chat session and reconnect via the accesspoint.

Before you say anything, this is just a scenario that is seldom say
with a laptop, because most people power down their laptop. I once did
it (office -> GPRS -> DSL), and the same problems ensue here. (I did
it, because I considered it important that I catch somebody online ;) )

> 
> > The important property here is, that openmoko needs to understand
> > first of all that there are different destinations: e.g. Internet, MMS
> > service, private networks (via CSD, via VPN).
> 
> who needs to understand that?  libmokonet and the preferences app needs
> to understand it, true.  but the applications certainly not.
Well, most applications not. Some applications might want to
understand it, e.g. a MMS client. 

> oh, you want to do per-application based policy routing? that's
> certainly a non-trivial task to do.  Nothing that I think openmoko would
> be able to look into for at least the next six months.
It's not trivial. Adding it later makes it only slightly harder.

> 
> > We should intercept connect() and show a dialog, probably defaulting
> > to "Internet" destinations.
> 
> no, that is ugly and would resemble the idea of personal firewalls.
> 
> which network packets to route to where, and which connections to accept
> and which not is the job of the kernel network stack.  We have _tons_ of
> tools to do stateful packet filtering, policy routing, traffic shaping,
> and combinations thereof (e.g. you can do stateful routing, selecting a
> route at connection startup time).

Yes. Sorry for my offensive implementation ideas. I just wanted to
sketch some solution to the problem. Actually, it was the first idea
how to implement it came to me.

> 
> > We should provide an openmoke_connect_tcp_socket(...) function in the
> > API, where the app can finetune which connection properties it needs.
> > (It might even go so far: "I need a long running connection", "I need
> > a connection with maximum bandwidth", ...)
> 
> I don't think the applications should care about this.  This is
> non-standard and diverges way too much from the usual way how tcp/ip and
> sockets work.

Yes. OTOH, a mobile device that has multiple network devices
"builtin", is not the usual device. The usual TCP/IP host does have
a default route, and that's it.


> 
> Somehow, the user-defined preferences/policies need to be translated in
> policy routing and packet filtering configuration.  This policy is
> always present, and does not require any special application support.
> 
> If you want to interactively permit/route/... connections, then this
> will most likely need to be done via NFQUEUE mechanisms.  You can QUEUE
> all packets that connection tracking deems NEW, and then return a
> verdict into the kernel.  I believe this is how e.g. the NuFW personal
> firewall handles this.

Agreed, as I said, I provided one possible way to do the tracking as
illustration that it's possible and not necessarily that complicated.

> 
> Thus, I argue that any such connection policy implementation
> a) does not depend on explicit application support but works with all
>    existing applications, without modifying them, system libraries or
>    kernel code
> b) uses existing infrastructure such as iproute2/tc/iptables/NFQUEUE
> c) uses files in the filesystem to specify the policies
> d) will have some userspace management daemon and/or control programs
>    storing the policies.
> e) application packages (ipk's) just provide a policy file with the
>    default policy
> 
> > This can be implemented by patching the upstream libc, 
> 
> sorry, but: over my dead body.

I cannot even claim that I wrote the mail after midnight :(

Andreas