IBM ARTour Kickoff

ARtour kickoff in San Mateo, 8/15/96. See http://www.raleigh.ibm.com

One-line summary

Protocol gateway to a variety of wide-area wireless that provides sockets interface and does various network level optimizations.

Client "agent" at network level talks to its peer on a server (which is behind the physical network gateway): like MOWGLI or evil twin; gives sockets API and provides protocol gateway (ie no TCP/IP over wireless).
"Optimized access" for TCP/IP legacy apps with no modification. Apps that don't tolerate timeouts well, etc. may need to be modified. (Intel was trying to enable this in middleware). Apps that don't use network efficiently will work but perform poorly.
Client: DOS/Win with IBM TCP/IP for DOS or OS/2; server peer: OS/2 or AIX; gateway to physical network: AIX on RS6k with X.25 card. Single gateway can gateway to multiple WWANs; ARtour has provision for switching among available ones (can switch TCP on the fly).
CDPD: ARtour will run on top of it even tho CDPD provides its own full stack. (Trivium: CDPD bills you before compression, so you should always do it at the client.)
Wireline encryption and authentication via CDMF (commercial deriv. of DES), all the way to the gateway (scenario: gateway is also intranet firewall)
SNMP-aware AIX wireless network graphical monitor app (topology/users, not QoS)
Standard optimizations: header compression/reduction, stream compression, packet filtering, connection muxing, etc.
Claim: network-level adaptation to QoS as you switch networks by varying compression, etc.
Currently works w/ARDIS, RAM, ARDIS; others coming.
Software developer program: get a free modem, free access to IBM gateway, cheap airtime on partner networks.

API for interposing transport-level or app-level agents, intended for apps that export well-circumscribed API.
HTTP header compression, forms differencing via CGI, HTML stream compression, etc. Very much like MOWGLI. (Claim: 90% reduction in some cases for Web traffic. Basis of claim is differencing of CGI forms where only a few bytes of content actually differ!)
Images: currently, passed through. Future, user will be able to specify certain datatypes should not be xmitted to client.
CLient-side cache: you hardwire the refresh interval! Just an extension of the browser mechanism for cache consistency. (They shoudl be refreshing cache when reconnected to wireline! They didn't mention this, but they do mention priming the cache before disconnecting.) Future plan: cache refresh policy can be based on URL's, etc. (MOWGLI has something like this for locking items in client cache)
"Differencing"of CGI-generated pages (i.e. run consecutive CGI reqs to same service, and run "diff" at the server peer). Not clear how general/extensible this approach is.
"This is not an ad-hoc surfing product, but a business tool [for accessing web-based c/s apps, etc.]. You won't pay to surf the web over wireless."
Currently in beta! Expect release end of year.
Things that itdoes not seem to do: traffic choreographing; compression in the cache.
They are actively courting customers to adopt this as a middleware standard. Their main concern: new platforms, new networks.