Once you start networking subnets together, you have to have real IP addresses (or put the whole network behind a series of NATs, which is fairly ugly).
You also need to start running a real routing protocol, e.g. RIPv2 for small networks or OSPF for larger ones. Once it gets complex enough, you need BGP to handle multiple exit routes to the Internet, and you're at the level of complexity of a reasonable size corporate network. Certainly doable but would be a significant effort for hobbyists, compared to the reasonable cost of just buying an Internet link.
You could also look into mobile ad hoc networks, which do the routing setup automagically, but they are still in the research stage and mainly aimed at local area networks.
IPv6 is most likely to take off in 2003, when UMTS Release 5 starts being deployed - UMTS is the European 3G mobile phone standard, and mandates that any device that does multimedia must use IPv6 (ordinary phones can just use IPv4 behind a NAT, as they do now with GPRS in Europe). This is one of the key drivers for adoption of IPv6, but it will take a while before IPv6 filters into corporations and the home through the influence of IPv6 phones. Internet-enabled appliances might also be a driver for IPv6 but I'm not sure they'll sell in sufficient numbers.
Most router vendors (Cisco, Nortel, Ericsson,...), and most OSs (Linux, Solaris 8, FreeBSD, Windows XP,...), already have IPv6 support, though some vendors are taking time to add the full set of routing protocols on top of IPv6.
For WLANs, IPv4 with NAT will be fine for some time.
Unfortunately Palm devices do crash, and so do WinCE devices by all accounts. I've been using a Palm and more recently a Handspring for some years, and I like the system as a whole, but the occasional crashes are annoying. Once I even had a crash a minute or two after an earlier crash... The Palm OS is very similar to MacOS (pre MacOS X) or Windows 3.x - applications have to hand back the CPU to the OS (cooperative multi-tasking), so it's very easy for a bad app to mess things up. In fact it's worse than Win 3.x, because the in-memory state is still there after a crash, so you can sometimes get into a state where you have to hard-reset (i.e. lose all memory state).
The Palm concept and applications are great, but the OS is really quite poor and should have been replaced a while back. The OS's lack of true multi-tasking is one reason why WinCE has done quite well in companies that want wireless applications.
QoS (quality of service) is not just about giving one class of traffic priority over another - you typically allocate a guaranteed share of bandwidth to each class, and in some cases limit the maximum usable by one class.
Also, QoS only currently works on private IP networks - there is no way of billing QoS traffic used to a user or content provider at present in the Internet, and this is unlikely to happen given that QoS has taken a long time to take off even in private networks.
Each customer of a service provider offering a QoS service buys a certain amount of Voice, Premium, Standard and Best Effort traffic (to use some common names for classes of service) for each site, e.g. 1 Mbps of Voice and 2 Mbps of Premium for their New York office. The provider won't let them send more than 1 Mbps of traffic from that site marked as Voice, i.e. it 'polices' the traffic against the customer contract for that site.
This means that any QoS abuse would be limited to that customer's QoS service, and would have NO extra impact on the network compared to normal customer usage of QoS.
If you have proper security, both email abuse and QoS abuse can be prevented - since QoS abuse would be much more costly to the customer (by stopping business applications from working over the network), it would be stamped on much more quickly. But, like voicemail and toll fraud, it will probably always happen - it's a question of preventing as much as possible, and detecting and stopping it as quickly as possible when it does happen, as Bruce Schneier has been saying for a while.
Thanks for the pointers. I've played with Cygwin/XFree86 and it took over the whole screen - once it can share the screen, letting some windows operate under X and others run native Windows apps, it will be very useful. I look forward to a GNOME on Windows port using Cygwin/XFree86, to avoid the need for commercial software such as U/WIN and most X servers.
One key point is that many Windows to *nix porting tools exist, including freeware options such as WINE. Not so many Unix to Windows porting tools exist, and fewer are freeware - until they are as good as the Windows to Unix tools, the temptation is for software companies to write to Windows APIs and then port to Unix.
A big obstacle for adopting open source in the Windows world is lack of understanding of the benefits. The Windows culture is all about commercialware and shareware; even 'freeware' means binary-only software. Providing an easy to install set of open source tools for Windows is not a bad idea - it would be much easier for newbies to experiment with this, and if it included a set of tutorials (most are on the web already) it could make quite a big contribution to educating people about Linux/Unix culture.
I'm thinking about developers and power users here, who might want to experiment with Perl, Unix scripting, GIMP, and other handy open source tools. Of course, it might be better in the long run to just install Linux, but incremental upgrades are a big reason why Windows won over OS/2 (you could try Windows 3.x but retreat to the safety of DOS without problems). Now people are running native mode Windows (NT and 2000) because it is more stable, faster, etc - why not make an incremental 'Linux tools on Windows' setup, allowing upgrade to true Linux later? Ideally, someone would take Cygwin and a bunch of other tools, and put them on a single CD including much of what's in a current Linux distro. I end up doing this on some systems, but a ready-made CD with installer would be much easier and more complete - no more systems with Cygwin but without Perl...
The majority of users in business have to use Windows on their desktop/laptop and would get in trouble if they installed Linux, particularly if the multiboot install messed up and stopped Windows booting. Having an open source distro for Windows would be a great way to provide some benefits... 'Linux for Windows' with an easy upgrade to 'true Linux'.
I really hope we can avoid bulk SMS without very carefully controlled opt-in... It's bad enough when I go to Italy and get 'welcome to operator Foo' spam on roaming to a new operator.
Your comments seem quite specific to Australia - when in Europe I've had little trouble sending SMSs to people back home, although some European operators don't seem to support this, so I have had to roam to a new one occasionally.
Pre-paid SMS internationally didn't work for some time but someone else on this thread said this was now working.
One of the most interesting stories I heard was that when carriers opened up to inter-carrier SMS, *every carrier's* SMS volume went up 20%. Shouldn't be a surprise really, that's why (eventually) the world went to Internet email, after a long period in the Eighties and early Nineties when proprietary email islands dominated... This means that enlightened operators should just open up inter-carrier SMS right now, as they will end up gaining in outbound SMS volumes.
SMS in Europe has achieved a critical mass, so that you know everyone with a mobile phone has SMS, and almost everyone has a mobile of course. Email in the US achieved a similar critical mass much earlier, at least a few years ago, which is why the various wireless email systems have held off true interoperable SMS.
US regulation is the problem
on
SMS vs. E-mail?
·
· Score: 2
A big problem is that the US regulator, the FCC, decided to simply license spectrum for cellular and PCS services, not to mandate a technology. While this was admirably laissez faire, it meant that operators and device/network vendors compete with different technologies: AMPS (analogue), D-AMPS/TDMA, CDMA and GSM. Nowhere else in the world has four actively used technologies, and almost nowhere else is still using analogue.
The European regulators took the view that a single standard would promote competition better - everyone uses GSM, so consumers can choose from a bigger pool of GSM phones, GSM operators and so on, than if there were multiple fragmented standards.
The European market is not really more regulated than the US, it's just that they took the opportunity to standardise the technology not just the spectrum. The result is that GSM now has just over 500 million users world-wide, about 70% of the market, and is gaining share in the US and most other places.
Re:Traveling with Cingular Wireless GSM phone
on
SMS vs. E-mail?
·
· Score: 2
That depends on your coverage area - some Cingular phones use TDMA, some use GSM, and in some areas customers are having TDMA phones exchanged for GSM.
See http://www.uwcc.org/pressrelease/uwccdoc32348.html
Cringely's satellite setup had a crap uplink which I assume was dialup. Assuming the satellite downlink is 2 Mbps, and the modem 33.6 Kbps on the uplink, the ratio between downlink and uplink is about 60.
On a big download, he would receive Ethernet style 1500 byte packets on the downlink, and send 40 byte TCP ACKs on the uplink. Unfortunately 1500 / 40 is 37.5 - he would need to send 2,000,000 / 37.5 = 53 Kbps of ACK packets over his 33.6 modem, so his downlink is reduced to about 1.3 Mbps when he's using TCP.
This is a bit of an artificial example but it does illustrate why extreme asymmetry is a bad idea with TCP, and of course any other traffic on the uplink would slow things even more. There is some work on optimising TCP to solve this, e.g. ACK filtering and ACK reconstruction.
BTW, high latency still sucks because TCP's ability to ramp up its congestion window after some packet losses is controlled by the round trip timer - high latency means a slow ramp up after every significant loss, which is particularly bad if you go into slow start and have to start from one packet again.
In this case it was probably more latency than asymmetry because his link was unlikely to be 2 Mbps.
You probably don't want to cuddle up to an 802.11b device - 2.4 GHz is the same frequency used for microwave ovens, though 802.11b uses much lower power of course.
It all depends what you are trying to do....It's unlikely a LUG is building a 128 Gbps backplane router, to say the least.
A Pentium or even a 486 is fine for most WAN links - e.g. I run a 1 Mbps ADSL connection with a Linux firewall based on an old 486/75 laptop. Most Cisco remote site routers are slower than this - the old 2500 was about the same as a 386.
That's different - probably Microsoft updated/usr/bin/clear in XENIX, under a proprietary license, before that was transferred to SCO, also under license. So nothing shady there.
Good point about the need for email - one of the biggest gaps in WAP is that you can't send a WAP page to someone via SMS so that the links work from their SMS view on the phone.
WAP is a set of protocols and markup language (WML) that runs over GSM, TDMA, CDMA, GPRS and many other transports.
GPRS will give something like 10 to 40 Kbps (current published measurements on a UK deployment peg it at about 10 Kbps currently). The point of GPRS is not that it's faster than traditional GSM/TDMA/CDMA circuit switched WAP, though it should be a bit better; its key benefit is that your phone or PDA or laptop is always connected.
This means that applications on the phone can get updates from content sites as and when you need them, using IP, without having to use SMS. For example, an airline reservation + itinerary set up through your PC could be beamed to your mobile phone, and updated as flights are cancelled, allowing you to re-book.
GPRS will also mean that you can check your stocks, or whatever page you frequently want to see, with only a few seconds delay - no need to 'dial' the WAP site.
I think GPRS will really take off if phones end up looking more like Palm-type PDAs - this is enough screen area to make web browsing useful (based on using AvantGo on the Palm, which is very usable). A wireless always-on connection to a PDA/smartphone would be great - ideally using a full HTML browser but with cut-down web pages.
Wireless is not just about low bandwidth - it's about highly variable bandwidth, high error rates, and latency sometimes measured in seconds.
Here are some of the things that TCP in particular has trouble with:
* Poor radio conditions lead to increased error correction (GPRS changes coding schemes on the fly) and re-transmissions (typically, 50% of all ethernet-sized packets are retransmitted because the basic medium is quite liable to corruption). Typical frame error rates are 1 to 2%, and errors tend to happen in bursts.
* Competition from voice calls or other data traffic in a cell, and lack of dedicated per-cell bandwidth (timeslots) for data traffic, lead to huge variations in bandwidth available.
The impact on TCP is that it frequently goes into slow start (because a whole series of packets is dropped by burst errors - TCP-Reno, the commonest implementation these days, is very sensitive to this). This means you go back to sending only one packet at a time (window size of one), then double the window size each ACK round-trip-time, until you get to half of your previous window size, when you start increasing linearly.
There is a lot of work going on to optimise TCP for wireless, following on from earlier work that optimised it for long fat pipes (e.g. SACK and window scaling). See http://www.aciri.org/floyd/tcp_small.html for a good survey. The key point is that wireless TCP performance has very little to do with TCP's behaviour on a link that has a constant 2400 bps bandwidth, a constant latency, and probably lower frame error rates.
It would have been better if the WAP people had just improved TCP, or created TCP gateways to the outside world, but plain unmodified TCP is not very usable in wireless. Apart from TCP, most of the WAP protocols could have been avoided, and certain WML was a mistake, but reduction of header overheads (IP, TCP and HTTP) and page sizes is important, so this would have had to be done on top of IP somehow. NTT DoCoMo's i-mode does prove that this is possible, though the technical details are not clear beyond their use of cHTML.
The real issue with WAP is terrible usability and poor implementations of browsers, WAP gateways, WAP servers and WML content - e.g. the Back button is dependent on the site coding it into WML, so sometimes you just can't go back, and frequently you get 'No gateway response' on trying a new site.
Also, it's very hard to report problems to WAP sites since they are not smart enough to include an SMS number where you could send them a report (and the problem could be anywhere between browser and site, in any case).
Also, have a look at the presentation at http://kodama.open-it.org/roadmap/index.html - this outlines how the OpenIT group is working on projects to integrate Ganymede with LDAP, both as a frontend protocol and backend storage system (Ganymede currently stores its data in memory). The main OpenIT site is at http://www.open-it.org/.
It may also be worth investigating how you can get Win2K clients to authenticate against a Unix/LDAP server - in the NT world, some links to follow are http://www.citi.umich.edu/projects/singlesignon/po ster2.html (which has integrated NT's login process with the Unix/Linux PAM framework) and http://www.smartcard.ust.hk/tutorials/smartlogon2. htm (good set of links on GINA, the NT login DLL that can integrate with third party authentication mechanisms).
Fortunately, Open is such a lame service that not many people will use it. The shopping sites are a small subset of what you can find on the Net, and you have to go online continually just to compose an email.
Most amusingly, the IR-based protocol between keyboard and set top box has no error recovery, so it's very easy to just type too fast and have it *lose characters*. Brilliant engineering...
Re:...when pigs fly and IPv6 is implemented
on
Smart Routers
·
· Score: 2
A few misconceptions here:
1) QoS (quality of service, the main use of 'smart routers', and doable today) is nothing to do with censorship. First of all, it is fairly pointless to deploy QoS on one part of an end to end Internet connection, so QoS is not used in the average Internet network. Instead, QoS technology is used on private IP networks used by businesses - either 'true' private networks, which run over leased lines or ATM/Frame Relay virtual circuits; or virtual private networks (VPNs), which in the IP world typically use IPSec or MPLS.
What happens is that businesses are sold more expensive, more secure, and higher QoS value added IP services that still save them money over separate ATM/FR services. The carriers rely on these value added services to make a profit(particularly given the telecoms downturn), particularly compared to basic dialup and ADSL/cable Internet access services. In other words, business users subsidise consumers.
This is very similar to the airlines - the existence of first and business class, etc, is another form of subsidy for consumers. You should be happy that QoS, VPNs and other value added services are being sold to businesses - they will fund network expansion (as business Internet access has done for the last five or more years) and generally make things faster and better for consumers.
2) *No new standards are required* - I work for a company that enables carriers to do all this stuff with plain old IPv4 routers. The biggest myth about IPv6 is that it will improve QoS - it won't make any difference, and has only one QoS feature (the flow label) over IPv4, which feature will require a new end-to-end QoS reservation approach that is unlikely to take over.
The people who have designed IPv6 have taken immense care to make the transition from IPv4 as easy as possible, e.g. through allowing automatic creation of IPv6 tunnels over IPv4 domains (6to4).
As with QoS, the transition to IPv6 will be funded by companies - with modern technology, the extra cost of running IPv6 on hosts vs. IPv4 is quite trivial, so even your mobile phone will have IPv6 in time, avoiding the hassles of NAT and making mobile IP much more efficient (roaming from wireless LAN to 3G networks without changing your IP address or having your sessions drop).
You might like to try reading up on these technologies before forming opinions on them - good places to start are qosforum.com, mplsrc.com and ipv6forum.com.
Re:Application Developers..
on
Smart Routers
·
· Score: 2
The first thing anyone does when deploying 'smart routers', aka QoS, is re-mark all traffic that is not from specific applications to best effort - this has the effect of re-writing any 'high priority' settings in the IP Precedence or Type of Service bits.
I don't quite see how 'GSM won the standards war in the US' - check www.gsmworld.com for the stats, and it's clear that the number of GSM subscribers in the US is tiny. AT&T Wireless are converting from TDMA to GSM/GPRS, and then W-CDMA, but Sprint, Cingular and others are resolutely CDMA2000, largely because that lets them re-use existing spectrum whereas W-CDMA demands new spectrum.
EDGE is as you say, the key point is that it lets you upgrade to higher speeds within existing spectrum, without a complete overhaul of the radio access network, but it's going to be quite wide-spread. CDMA2000 and W-CDMA will take a long time to roll out to high coverage (some say 2006 or 2007), and EDGE or even GPRS will be used as fill-in for all the rural areas where new, smaller cells can't be justified yet.
Applications will need to be highly adaptive to varying bandwidth and error rates, even in the brave new 3G world.
The security world has a concept of 'security assurance' - this is the confidence that you can have that a given set of security features (e.g. granular privileges, ACLs, audit logging, label-based security, etc.) actually work. This is taken from the old Orange Book used to rate computer system security, which has its problems but remains a useful model.
Bruce Schneier has been talking a lot about the need for monitoring and response to intrusions, based on the reasonable premise that you can't prevent 100% of all intrusions for all time (even OpenBSD has had remote root holes some years ago, and most holes are actually due to specific applications). If you accept this, it seems sensible to define goals for monitoring and response times.
Defining such assurance levels is not easy - on one project, I wrote requirements for security assurance that defined quantified goals for such things as 'minimum time to detect break-in' and 'minimum time to respond to and stop break-in'.
If you are interested in quantifying requirements for security (and other 'soft' requirements such as performance, availability, reliability, usability and flexibility), have a look at Tom Gilb's work - his site is at http://www.result-planning.com/ and most useful book isn at http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp ?theisbn=0201192462&vm=
The world really needs software-defined radio to achieve the goal of one phone that works everywhere.
There are already 3 different digital cell phone standards in North America (CDMA, TDMA and GSM), and at least one more in Japan (PDC) - the rest of the world uses GSM, but life is going to get much more complicated with 2.5G and 3G:
- 2.5G (data rates of 40 to 100 Kbps, packet mode)is mainly GSM or CDMA based, but EDGE is a new radio transmission technology
- 3G (data rates up to 384 Kbps when mobile, 2 Mbps in buildings) will use W-CDMA in most of the world, with CDMA2000 picking up much of North America. China has just decreed yet another 3G radio standard, TD-SCDMA.
So, if you want a phone that roams onto all common networks today or in the 2.5/3G world, you'll need a lot of different radio standards supported.
While I can't tell whether this development is truly important, EETimes seems to think it is, and software-defined radio will be very useful. Just think, you could download a new radio module before going to another country, rather than having to rent a phone and tell everyone your temporary phone number (just like GSM today, but that only has 70% market share globally, even though it just hit the half-billion subscriber mark).
Let's call it 'source available'
on
Mundie Responds
·
· Score: 2
Microsoft has crafted the term 'shared source' very carefully, using the connotations of sharing to good effect. In fact, there is precious little sharing going on - only selected large customers get the source, and they are not allowed to redistribute it.
Let's call this model 'source available' - in other words, it is proprietary software that has source available, just like most RTOSs, VAX/VMS, many early mainframe OSs, and so on.
Slashdot Mirror
Once you start networking subnets together, you have to have real IP addresses (or put the whole network behind a series of NATs, which is fairly ugly).
You also need to start running a real routing protocol, e.g. RIPv2 for small networks or OSPF for larger ones. Once it gets complex enough, you need BGP to handle multiple exit routes to the Internet, and you're at the level of complexity of a reasonable size corporate network. Certainly doable but would be a significant effort for hobbyists, compared to the reasonable cost of just buying an Internet link.
You could also look into mobile ad hoc networks, which do the routing setup automagically, but they are still in the research stage and mainly aimed at local area networks.
IPv6 is most likely to take off in 2003, when UMTS Release 5 starts being deployed - UMTS is the European 3G mobile phone standard, and mandates that any device that does multimedia must use IPv6 (ordinary phones can just use IPv4 behind a NAT, as they do now with GPRS in Europe). This is one of the key drivers for adoption of IPv6, but it will take a while before IPv6 filters into corporations and the home through the influence of IPv6 phones. Internet-enabled appliances might also be a driver for IPv6 but I'm not sure they'll sell in sufficient numbers.
...), and most OSs (Linux, Solaris 8, FreeBSD, Windows XP, ...), already have IPv6 support, though some vendors are taking time to add the full set of routing protocols on top of IPv6.
Most router vendors (Cisco, Nortel, Ericsson,
For WLANs, IPv4 with NAT will be fine for some time.
Unfortunately Palm devices do crash, and so do WinCE devices by all accounts. I've been using a Palm and more recently a Handspring for some years, and I like the system as a whole, but the occasional crashes are annoying. Once I even had a crash a minute or two after an earlier crash... The Palm OS is very similar to MacOS (pre MacOS X) or Windows 3.x - applications have to hand back the CPU to the OS (cooperative multi-tasking), so it's very easy for a bad app to mess things up. In fact it's worse than Win 3.x, because the in-memory state is still there after a crash, so you can sometimes get into a state where you have to hard-reset (i.e. lose all memory state).
The Palm concept and applications are great, but the OS is really quite poor and should have been replaced a while back. The OS's lack of true multi-tasking is one reason why WinCE has done quite well in companies that want wireless applications.
QoS (quality of service) is not just about giving one class of traffic priority over another - you typically allocate a guaranteed share of bandwidth to each class, and in some cases limit the maximum usable by one class.
Also, QoS only currently works on private IP networks - there is no way of billing QoS traffic used to a user or content provider at present in the Internet, and this is unlikely to happen given that QoS has taken a long time to take off even in private networks.
Each customer of a service provider offering a QoS service buys a certain amount of Voice, Premium, Standard and Best Effort traffic (to use some common names for classes of service) for each site, e.g. 1 Mbps of Voice and 2 Mbps of Premium for their New York office. The provider won't let them send more than 1 Mbps of traffic from that site marked as Voice, i.e. it 'polices' the traffic against the customer contract for that site.
This means that any QoS abuse would be limited to that customer's QoS service, and would have NO extra impact on the network compared to normal customer usage of QoS.
If you have proper security, both email abuse and QoS abuse can be prevented - since QoS abuse would be much more costly to the customer (by stopping business applications from working over the network), it would be stamped on much more quickly. But, like voicemail and toll fraud, it will probably always happen - it's a question of preventing as much as possible, and detecting and stopping it as quickly as possible when it does happen, as Bruce Schneier has been saying for a while.
Thanks for the pointers. I've played with Cygwin/XFree86 and it took over the whole screen - once it can share the screen, letting some windows operate under X and others run native Windows apps, it will be very useful. I look forward to a GNOME on Windows port using Cygwin/XFree86, to avoid the need for commercial software such as U/WIN and most X servers.
One key point is that many Windows to *nix porting tools exist, including freeware options such as WINE. Not so many Unix to Windows porting tools exist, and fewer are freeware - until they are as good as the Windows to Unix tools, the temptation is for software companies to write to Windows APIs and then port to Unix.
A big obstacle for adopting open source in the Windows world is lack of understanding of the benefits. The Windows culture is all about commercialware and shareware; even 'freeware' means binary-only software. Providing an easy to install set of open source tools for Windows is not a bad idea - it would be much easier for newbies to experiment with this, and if it included a set of tutorials (most are on the web already) it could make quite a big contribution to educating people about Linux/Unix culture.
I'm thinking about developers and power users here, who might want to experiment with Perl, Unix scripting, GIMP, and other handy open source tools. Of course, it might be better in the long run to just install Linux, but incremental upgrades are a big reason why Windows won over OS/2 (you could try Windows 3.x but retreat to the safety of DOS without problems). Now people are running native mode Windows (NT and 2000) because it is more stable, faster, etc - why not make an incremental 'Linux tools on Windows' setup, allowing upgrade to true Linux later? Ideally, someone would take Cygwin and a bunch of other tools, and put them on a single CD including much of what's in a current Linux distro. I end up doing this on some systems, but a ready-made CD with installer would be much easier and more complete - no more systems with Cygwin but without Perl...
The majority of users in business have to use Windows on their desktop/laptop and would get in trouble if they installed Linux, particularly if the multiboot install messed up and stopped Windows booting. Having an open source distro for Windows would be a great way to provide some benefits... 'Linux for Windows' with an easy upgrade to 'true Linux'.
I really hope we can avoid bulk SMS without very carefully controlled opt-in... It's bad enough when I go to Italy and get 'welcome to operator Foo' spam on roaming to a new operator.
Your comments seem quite specific to Australia - when in Europe I've had little trouble sending SMSs to people back home, although some European operators don't seem to support this, so I have had to roam to a new one occasionally.
Pre-paid SMS internationally didn't work for some time but someone else on this thread said this was now working.
One of the most interesting stories I heard was that when carriers opened up to inter-carrier SMS, *every carrier's* SMS volume went up 20%. Shouldn't be a surprise really, that's why (eventually) the world went to Internet email, after a long period in the Eighties and early Nineties when proprietary email islands dominated... This means that enlightened operators should just open up inter-carrier SMS right now, as they will end up gaining in outbound SMS volumes.
SMS in Europe has achieved a critical mass, so that you know everyone with a mobile phone has SMS, and almost everyone has a mobile of course. Email in the US achieved a similar critical mass much earlier, at least a few years ago, which is why the various wireless email systems have held off true interoperable SMS.
A big problem is that the US regulator, the FCC, decided to simply license spectrum for cellular and PCS services, not to mandate a technology. While this was admirably laissez faire, it meant that operators and device/network vendors compete with different technologies: AMPS (analogue), D-AMPS/TDMA, CDMA and GSM. Nowhere else in the world has four actively used technologies, and almost nowhere else is still using analogue.
The European regulators took the view that a single standard would promote competition better - everyone uses GSM, so consumers can choose from a bigger pool of GSM phones, GSM operators and so on, than if there were multiple fragmented standards.
The European market is not really more regulated than the US, it's just that they took the opportunity to standardise the technology not just the spectrum. The result is that GSM now has just over 500 million users world-wide, about 70% of the market, and is gaining share in the US and most other places.
That depends on your coverage area - some Cingular phones use TDMA, some use GSM, and in some areas customers are having TDMA phones exchanged for GSM.
l
See http://www.uwcc.org/pressrelease/uwccdoc32348.htm
Cringely's satellite setup had a crap uplink which I assume was dialup. Assuming the satellite downlink is 2 Mbps, and the modem 33.6 Kbps on the uplink, the ratio between downlink and uplink is about 60.
On a big download, he would receive Ethernet style 1500 byte packets on the downlink, and send 40 byte TCP ACKs on the uplink. Unfortunately 1500 / 40 is 37.5 - he would need to send 2,000,000 / 37.5 = 53 Kbps of ACK packets over his 33.6 modem, so his downlink is reduced to about 1.3 Mbps when he's using TCP.
This is a bit of an artificial example but it does illustrate why extreme asymmetry is a bad idea with TCP, and of course any other traffic on the uplink would slow things even more. There is some work on optimising TCP to solve this, e.g. ACK filtering and ACK reconstruction.
BTW, high latency still sucks because TCP's ability to ramp up its congestion window after some packet losses is controlled by the round trip timer - high latency means a slow ramp up after every significant loss, which is particularly bad if you go into slow start and have to start from one packet again.
In this case it was probably more latency than asymmetry because his link was unlikely to be 2 Mbps.
You probably don't want to cuddle up to an 802.11b device - 2.4 GHz is the same frequency used for microwave ovens, though 802.11b uses much lower power of course.
It all depends what you are trying to do....It's unlikely a LUG is building a 128 Gbps backplane router, to say the least.
A Pentium or even a 486 is fine for most WAN links - e.g. I run a 1 Mbps ADSL connection with a Linux firewall based on an old 486/75 laptop. Most Cisco remote site routers are slower than this - the old 2500 was about the same as a 386.
That's different - probably Microsoft updated /usr/bin/clear in XENIX, under a proprietary license, before that was transferred to SCO, also under license. So nothing shady there.
Good point about the need for email - one of the biggest gaps in WAP is that you can't send a WAP page to someone via SMS so that the links work from their SMS view on the phone.
WAP is a set of protocols and markup language (WML) that runs over GSM, TDMA, CDMA, GPRS and many other transports.
GPRS will give something like 10 to 40 Kbps (current published measurements on a UK deployment peg it at about 10 Kbps currently). The point of GPRS is not that it's faster than traditional GSM/TDMA/CDMA circuit switched WAP, though it should be a bit better; its key benefit is that your phone or PDA or laptop is always connected.
This means that applications on the phone can get updates from content sites as and when you need them, using IP, without having to use SMS. For example, an airline reservation + itinerary set up through your PC could be beamed to your mobile phone, and updated as flights are cancelled, allowing you to re-book.
GPRS will also mean that you can check your stocks, or whatever page you frequently want to see, with only a few seconds delay - no need to 'dial' the WAP site.
I think GPRS will really take off if phones end up looking more like Palm-type PDAs - this is enough screen area to make web browsing useful (based on using AvantGo on the Palm, which is very usable). A wireless always-on connection to a PDA/smartphone would be great - ideally using a full HTML browser but with cut-down web pages.
Wireless is not just about low bandwidth - it's about highly variable bandwidth, high error rates, and latency sometimes measured in seconds.
Here are some of the things that TCP in particular has trouble with:
* Poor radio conditions lead to increased error correction (GPRS changes coding schemes on the fly) and re-transmissions (typically, 50% of all ethernet-sized packets are retransmitted because the basic medium is quite liable to corruption). Typical frame error rates are 1 to 2%, and errors tend to happen in bursts.
* Competition from voice calls or other data traffic in a cell, and lack of dedicated per-cell bandwidth (timeslots) for data traffic, lead to huge variations in bandwidth available.
The impact on TCP is that it frequently goes into slow start (because a whole series of packets is dropped by burst errors - TCP-Reno, the commonest implementation these days, is very sensitive to this). This means you go back to sending only one packet at a time (window size of one), then double the window size each ACK round-trip-time, until you get to half of your previous window size, when you start increasing linearly.
There is a lot of work going on to optimise TCP for wireless, following on from earlier work that optimised it for long fat pipes (e.g. SACK and window scaling). See http://www.aciri.org/floyd/tcp_small.html for a good survey. The key point is that wireless TCP performance has very little to do with TCP's behaviour on a link that has a constant 2400 bps bandwidth, a constant latency, and probably lower frame error rates.
It would have been better if the WAP people had just improved TCP, or created TCP gateways to the outside world, but plain unmodified TCP is not very usable in wireless. Apart from TCP, most of the WAP protocols could have been avoided, and certain WML was a mistake, but reduction of header overheads (IP, TCP and HTTP) and page sizes is important, so this would have had to be done on top of IP somehow. NTT DoCoMo's i-mode does prove that this is possible, though the technical details are not clear beyond their use of cHTML.
The real issue with WAP is terrible usability and poor implementations of browsers, WAP gateways, WAP servers and WML content - e.g. the Back button is dependent on the site coding it into WML, so sometimes you just can't go back, and frequently you get 'No gateway response' on trying a new site.
Also, it's very hard to report problems to WAP sites since they are not smart enough to include an SMS number where you could send them a report (and the problem could be anywhere between browser and site, in any case).
Also, have a look at the presentation at http://kodama.open-it.org/roadmap/index.html - this outlines how the OpenIT group is working on projects to integrate Ganymede with LDAP, both as a frontend protocol and backend storage system (Ganymede currently stores its data in memory). The main OpenIT site is at http://www.open-it.org/.
o ster2.html (which has integrated NT's login process with the Unix/Linux PAM framework) and http://www.smartcard.ust.hk/tutorials/smartlogon2. htm (good set of links on GINA, the NT login DLL that can integrate with third party authentication mechanisms).
It may also be worth investigating how you can get Win2K clients to authenticate against a Unix/LDAP server - in the NT world, some links to follow are http://www.citi.umich.edu/projects/singlesignon/p
That was a joke, please adjust your satire detection threshold...
Fortunately, Open is such a lame service that not many people will use it. The shopping sites are a small subset of what you can find on the Net, and you have to go online continually just to compose an email.
Most amusingly, the IR-based protocol between keyboard and set top box has no error recovery, so it's very easy to just type too fast and have it *lose characters*. Brilliant engineering...
A few misconceptions here:
1) QoS (quality of service, the main use of 'smart routers', and doable today) is nothing to do with censorship. First of all, it is fairly pointless to deploy QoS on one part of an end to end Internet connection, so QoS is not used in the average Internet network. Instead, QoS technology is used on private IP networks used by businesses - either 'true' private networks, which run over leased lines or ATM/Frame Relay virtual circuits; or virtual private networks (VPNs), which in the IP world typically use IPSec or MPLS.
What happens is that businesses are sold more expensive, more secure, and higher QoS value added IP services that still save them money over separate ATM/FR services. The carriers rely on these value added services to make a profit(particularly given the telecoms downturn), particularly compared to basic dialup and ADSL/cable Internet access services. In other words, business users subsidise consumers.
This is very similar to the airlines - the existence of first and business class, etc, is another form of subsidy for consumers. You should be happy that QoS, VPNs and other value added services are being sold to businesses - they will fund network expansion (as business Internet access has done for the last five or more years) and generally make things faster and better for consumers.
2) *No new standards are required* - I work for a company that enables carriers to do all this stuff with plain old IPv4 routers. The biggest myth about IPv6 is that it will improve QoS - it won't make any difference, and has only one QoS feature (the flow label) over IPv4, which feature will require a new end-to-end QoS reservation approach that is unlikely to take over.
The people who have designed IPv6 have taken immense care to make the transition from IPv4 as easy as possible, e.g. through allowing automatic creation of IPv6 tunnels over IPv4 domains (6to4).
As with QoS, the transition to IPv6 will be funded by companies - with modern technology, the extra cost of running IPv6 on hosts vs. IPv4 is quite trivial, so even your mobile phone will have IPv6 in time, avoiding the hassles of NAT and making mobile IP much more efficient (roaming from wireless LAN to 3G networks without changing your IP address or having your sessions drop).
You might like to try reading up on these technologies before forming opinions on them - good places to start are qosforum.com, mplsrc.com and ipv6forum.com.
The first thing anyone does when deploying 'smart routers', aka QoS, is re-mark all traffic that is not from specific applications to best effort - this has the effect of re-writing any 'high priority' settings in the IP Precedence or Type of Service bits.
I don't quite see how 'GSM won the standards war in the US' - check www.gsmworld.com for the stats, and it's clear that the number of GSM subscribers in the US is tiny. AT&T Wireless are converting from TDMA to GSM/GPRS, and then W-CDMA, but Sprint, Cingular and others are resolutely CDMA2000, largely because that lets them re-use existing spectrum whereas W-CDMA demands new spectrum.
EDGE is as you say, the key point is that it lets you upgrade to higher speeds within existing spectrum, without a complete overhaul of the radio access network, but it's going to be quite wide-spread. CDMA2000 and W-CDMA will take a long time to roll out to high coverage (some say 2006 or 2007), and EDGE or even GPRS will be used as fill-in for all the rural areas where new, smaller cells can't be justified yet.
Applications will need to be highly adaptive to varying bandwidth and error rates, even in the brave new 3G world.
The security world has a concept of 'security assurance' - this is the confidence that you can have that a given set of security features (e.g. granular privileges, ACLs, audit logging, label-based security, etc.) actually work. This is taken from the old Orange Book used to rate computer system security, which has its problems but remains a useful model.
p ?theisbn=0201192462&vm=
Bruce Schneier has been talking a lot about the need for monitoring and response to intrusions, based on the reasonable premise that you can't prevent 100% of all intrusions for all time (even OpenBSD has had remote root holes some years ago, and most holes are actually due to specific applications). If you accept this, it seems sensible to define goals for monitoring and response times.
Defining such assurance levels is not easy - on one project, I wrote requirements for security assurance that defined quantified goals for such things as 'minimum time to detect break-in' and 'minimum time to respond to and stop break-in'.
If you are interested in quantifying requirements for security (and other 'soft' requirements such as performance, availability, reliability, usability and flexibility), have a look at Tom Gilb's work - his site is at http://www.result-planning.com/ and most useful book isn at http://www1.fatbrain.com/asp/bookinfo/bookinfo.as
The world really needs software-defined radio to achieve the goal of one phone that works everywhere.
There are already 3 different digital cell phone standards in North America (CDMA, TDMA and GSM), and at least one more in Japan (PDC) - the rest of the world uses GSM, but life is going to get much more complicated with 2.5G and 3G:
- 2.5G (data rates of 40 to 100 Kbps, packet mode)is mainly GSM or CDMA based, but EDGE is a new radio transmission technology
- 3G (data rates up to 384 Kbps when mobile, 2 Mbps in buildings) will use W-CDMA in most of the world, with CDMA2000 picking up much of North America. China has just decreed yet another 3G radio standard, TD-SCDMA.
So, if you want a phone that roams onto all common networks today or in the 2.5/3G world, you'll need a lot of different radio standards supported.
While I can't tell whether this development is truly important, EETimes seems to think it is, and software-defined radio will be very useful. Just think, you could download a new radio module before going to another country, rather than having to rent a phone and tell everyone your temporary phone number (just like GSM today, but that only has 70% market share globally, even though it just hit the half-billion subscriber mark).
Microsoft has crafted the term 'shared source' very carefully, using the connotations of sharing to good effect. In fact, there is precious little sharing going on - only selected large customers get the source, and they are not allowed to redistribute it.
Let's call this model 'source available' - in other words, it is proprietary software that has source available, just like most RTOSs, VAX/VMS, many early mainframe OSs, and so on.