There are quite a few ways to do optical switching - most do not involve per-packet forwarding since that would be very hard with optics. Many just set up an optical path through various nodes, and leave it established for days or months - you put IP, ATM or whatever into one end, and it pops out the other end, without the optical switches knowing what they are switching (like ATM PVCs).
One promising compromise is optical burst switching - here, the control plane operates electronically, with the ingress node sending a control packet saying where the burst (not yet sent) is to go. The optical switches set up suitable fibre+wavelength cross-connections to match the control packet's requirements. Then, after a specified delay to allow for setup, the actual data burst is sent along the all-optical path.
This avoids having to per-packet forwarding but still retains quite a lot of flexibility. One of the most interesting things is that IP-based protocols are likely to become the standard for setting up optical paths (probably via MPLS) - this makes it a lot easier to build systems that talk IP to the ingress nodes to configure the required paths. MPLS is already used in IP router + ATM switch based networks, but enabling it to control optical networks will mean you can have a single control mechanism across IP, ATM and optical domains.
There's some confusion over two concepts here: the time to switch SONET frames, which most people refer to as switching speed, and the time to fail over to another SONET fibre ring when one fibre fails (known as automatic protection switching).
If SONET cross-connects took 50-100ms to forward frames they would be slower than routers, of course.
Most people care about the per node latency - establishing new paths through the network is often done by management systems only, and can take tens of milliseconds upwards, particularly if it's not required for resilience to failure.
This article was interesting and made some good points about security levels and the robustness of UFS, but:
-/proc is hardly a big CPU overhead to generate and parse (the real criticism is that it's a mess, combining process and config/status info)
- lilo supports booting from serial, just like FreeBSD. Creating a boot disk is the standard way to avoid getting locked out of your system when you create a new kernel, although the FreeBSD bootloader feature mentioned sounds nice.
- linuxconf is a boon to those who are not Linux/Unix gurus, and the Red Hat/etc/sysconf file structure does make sense once you get past the initial proliferation of files. Like the/etc/rc* structures, this is largely a matter of taste.
I'm probably biased towards Linux, since I use that most, but I've used a lot of BSD and other Unix systems, including OpenBSD. But at least I don't claim to be 'very non-biased'!
I also really want a way of assigning a bundle of feature toggles to a single button (e.g. load images or not, allow ads/javascript or not). Opera has some (hard-coded) buttons that are very nice - one to load images when you press it, and another that used to render illegible pages readable by applying default formatting (until they broke this in 4.0...).
I doubt any end user will see a DNS name when they are trying to dial a number - the phone (or VoIP enabled app) will just let them dial a number, and the DNS lookups happen behind the scenes.
This isn't why wireless companies are failing, but TCP does have problems over wireless - e.g. packet drops are interpreted as congestion, when they could be due to a burst of data corruption.
There's a good article on TCP in the latest IP Journal that covers TCP over wireless, see www.cisco.com and search for IPJ. Issues are downloadable or you can sign up.
In your discussions with lawyers, you might want to raise the precedent set by another part of AT&T Labs - the UK arm, originally Olivetti-Oracle Research Labs, distributes OmniORB and VNC, which are either LGPLed or GPLed. I use both these products quite a lot and it's fair to say they generate some goodwill towards the lab. Details at http://www.uk.research.att.com/.
How can it be unreasonable for customers to say what features they do and don't want in a product?
Red Hat has to make feature decisions, like any company, that some customers don't like - however, it is entirely reasonable for customers to comment on what they want (ideally before the product is finalised!)
As for special things like USB support - Mandrake 7.1 (I think) and definitely 7.2 includes USB backported from 2.4 work.
I agree that Red Hat bashing for the sake of it is pointless, but feature/stability discussions are definitely worthwhile.
The problem is defining how the addressing and routing will work - every node will need to be running a routing protocol at least (something like RIP should be OK for a small network).
The nodes which have a wired connection to the Internet should advertise a default route with a suitably low metric - as these routes float through the RIP network, the one that 'wins' at any node is the route that represents the fewest hops to the wired Internet connection.
There are probably much slicker ways of doing this but they'd also be more complex to set up.
Probably all the wired-to-wireless gateways will need to do NAT. They should also do IPSec for those nodes that don't have WEP type encryption.
Re:Virtually No Coverage of Dynamic Routing
on
Linux Routers
·
· Score: 3
An implicit assumption of the book seems to be that you are setting up an edge router that provides Internet access - this is probably quite reasonable for 99% of cases, as I've yet to see anyone use a Linux router in the core of their network.
Imagestream and Nbase-Xyplex do make heftier core-style Linux routers / layer 3 switches, but they aren't very widely deployed.
I thought my K6-2/350 was quite fast enough - then I installed the latest bloatware, i.e. Mozilla,...
VMware is also quite CPU hungry - it's fine for most things, running Windows on Linux on this hardware with 256 MB RAM, but it could still do with a speed boost when booting (which doesn't run at full speed).
This isn't a trend I particularly like, but it seems to be happening in the Linux world as the GUI applications get better...
Good points mostly, but you seem to be saying that ATM is the only way to go for such big pipes - this is far from the case, particularly for IP traffic, due to the problems of scaling SAR on ATM router interfaces (i.e. slicing packets into cells then reassembling them). See http://www.juniper.net/techcenter/techpapers/20000 4-03.html for some background.
Most large providers seem to be going for packet over SONET for IP traffic, and will ultimately go for MPLS alongside this. Eventually, SONET may well disappear or shrink as DWDM-native protection/failover becomes available. The good news is that the ATM cell tax is going away, and the cost of managing networks is going down (every node will be an IP or MPLS router, or an optical switch). See http://www.mplsrc.com for more on MPLS, it provides most of the benefits of ATM with much less complexity and overhead.
DWDM (dense wave-division multiplexing) lets you run many wavelengths simultaneously within a single fibre - probably this pipe is already using this, but DWDM will continue to improve, meaning that you can just upgrade the kit at each end to upgrade your bandwidth. 1 Terabit, here we come...
Opera is also very annoying in its insistence that standards conformance is more important than being able to view a page - it sometimes is unable to view the page at all, showing a blank screen.
Most of the time it works well (it is my main Windows browser, and is very fast indeed), but the standards conformance should be selectable - i.e. a button that says 'do your best and forget standards'.
Unfortunately the Opera people seem to think selectable standards conformance is not important. The IETFers disagree, saying 'be strict in what you send and liberal in what you accept' - since Opera is on the receiving end of HTML, a 'liberal' option would be far more useful, and in the long run would promote web standards by selling more copies of Opera.
With Windows NT on top of VMware 1.x on Linux, I had really atrocious mouse performance (many stops in mouse movement, etc) with a PS/2 mouse (the physical mouse).
When I switched to a serial mouse performance was fine, which I put down to the mouse sampling rate being lower. This may have been fixed, but I expect the load would be higher.
In fact, you'd probably get best performance from using serial for the virtual and physical mice.
Patents have a finite lifetime, as do copyrights (though they keep getting extended). However there's no way that software can go into the public domain just because it is not patented - typically the lifetime for patents is much less than that for copyrights (e.g. 20 years vs 50).
Interesting - presumably something like the Linuxbios work would make it possible to boot off a floppy that has an ext2 filesystem, or even FAT? Presumably FAT is the way to go, since it was originally designed for floppies and must have the bad block avoidance stuff built in.
I've had the same problem with boot disks - on two NT machines and one Linux box, and about half a dozen floppies, I've been unable to make a Red Hat 6.2 bootnet.img boot disk. I fetched the.img file twice and did a cmp to make sure it was not corrupted, but I still can't get the damn thing to write to a floppy and not get corrupted - I suspect the floppies, as they were almost all very old and second hand.
Presumably what's happened is that the demand for floppies has dropped dramatically, so the disk vendors have had to cut costs equally dramatically to stay in business. Seems like quality has suffered in the process.
>>> I think any sort of copy operation performed through the GUI is automatically verified. This would explain why (especially floppies) copying via CLI is faster than drag'n'drop or "Send to A:"
This is not generally true, though perhaps some unusual GUIs do it. The overhead of verification is enough for most people to turn it off, even in the CLI world. The difference in speed is due to the overhead of GUI apps, no doubt - CLI copy tools evolved on much slower systems and are now blindingly fast.
In fact, when copying a full hard disk of files from a Win95 system to Windows NT via SMB via the Windows Explorer GUI, I was amazed to find a whole bunch of files missing. SMB had managed to quietly fail, with absolutely no errors, and of course the GUI had not noticed. (The problem went away when Win95 was the client to Samba on Linux - the bug was either in smbfs or in Win95's flaky server capabilities.)
You need to read up on IPv6 - the MAC address stays the same, when you move the device it either keeps its IP address (via Mobile IP, which IPv6 is quite good at) or gets a new one via various techniques (not just DHCP). I think ARP has gone away in IPv6, but there's something equivalent that generalises across most L2 protocols.
Slashdot Mirror
There are quite a few ways to do optical switching - most do not involve per-packet forwarding since that would be very hard with optics. Many just set up an optical path through various nodes, and leave it established for days or months - you put IP, ATM or whatever into one end, and it pops out the other end, without the optical switches knowing what they are switching (like ATM PVCs).
One promising compromise is optical burst switching - here, the control plane operates electronically, with the ingress node sending a control packet saying where the burst (not yet sent) is to go. The optical switches set up suitable fibre+wavelength cross-connections to match the control packet's requirements. Then, after a specified delay to allow for setup, the actual data burst is sent along the all-optical path.
This avoids having to per-packet forwarding but still retains quite a lot of flexibility.
One of the most interesting things is that IP-based protocols are likely to become the standard for setting up optical paths (probably via MPLS) - this makes it a lot easier to build systems that talk IP to the ingress nodes to configure the required paths. MPLS is already used in IP router + ATM switch based networks, but enabling it to control optical networks will mean you can have a single control mechanism across IP, ATM and optical domains.
There's some confusion over two concepts here: the time to switch SONET frames, which most people refer to as switching speed, and the time to fail over to another SONET fibre ring when one fibre fails (known as automatic protection switching).
If SONET cross-connects took 50-100ms to forward frames they would be slower than routers, of course.
Most people care about the per node latency - establishing new paths through the network is often done by management systems only, and can take tens of milliseconds upwards, particularly if it's not required for resilience to failure.
This article was interesting and made some good points about security levels and the robustness of UFS, but:
/proc is hardly a big CPU overhead to generate and parse (the real criticism is that it's a mess, combining process and config/status info)
/etc/sysconf file structure does make sense once you get past the initial proliferation of files. Like the /etc/rc* structures, this is largely a matter of taste.
-
- lilo supports booting from serial, just like FreeBSD. Creating a boot disk is the standard way to avoid getting locked out of your system when you create a new kernel, although the FreeBSD bootloader feature mentioned sounds nice.
- linuxconf is a boon to those who are not Linux/Unix gurus, and the Red Hat
I'm probably biased towards Linux, since I use that most, but I've used a lot of BSD and other Unix systems, including OpenBSD. But at least I don't claim to be 'very non-biased'!
I also really want a way of assigning a bundle of feature toggles to a single button (e.g. load images or not, allow ads/javascript or not). Opera has some (hard-coded) buttons that are very nice - one to load images when you press it, and another that used to render illegible pages readable by applying default formatting (until they broke this in 4.0...).
I doubt any end user will see a DNS name when they are trying to dial a number - the phone (or VoIP enabled app) will just let them dial a number, and the DNS lookups happen behind the scenes.
DSL and cable are not used for backbone links (e.g. provider to provider) - they are access links, linking the end customer to the network.
This isn't why wireless companies are failing, but TCP does have problems over wireless - e.g. packet drops are interpreted as congestion, when they could be due to a burst of data corruption.
There's a good article on TCP in the latest IP Journal that covers TCP over wireless, see www.cisco.com and search for IPJ. Issues are downloadable or you can sign up.
In your discussions with lawyers, you might want to raise the precedent set by another part of AT&T Labs - the UK arm, originally Olivetti-Oracle Research Labs, distributes OmniORB and VNC, which are either LGPLed or GPLed. I use both these products quite a lot and it's fair to say they generate some goodwill towards the lab. Details at http://www.uk.research.att.com/.
How can it be unreasonable for customers to say what features they do and don't want in a product?
Red Hat has to make feature decisions, like any company, that some customers don't like - however, it is entirely reasonable for customers to comment on what they want (ideally before the product is finalised!)
As for special things like USB support - Mandrake 7.1 (I think) and definitely 7.2 includes USB backported from 2.4 work.
I agree that Red Hat bashing for the sake of it is pointless, but feature/stability discussions are definitely worthwhile.
That's actually link layer encryption - end to end means host to host, e.g. IPSec transport mode.
The problem is defining how the addressing and routing will work - every node will need to be running a routing protocol at least (something like RIP should be OK for a small network).
The nodes which have a wired connection to the Internet should advertise a default route with a suitably low metric - as these routes float through the RIP network, the one that 'wins' at any node is the route that represents the fewest hops to the wired Internet connection.
There are probably much slicker ways of doing this but they'd also be more complex to set up.
Probably all the wired-to-wireless gateways will need to do NAT. They should also do IPSec for those nodes that don't have WEP type encryption.
An implicit assumption of the book seems to be that you are setting up an edge router that provides Internet access - this is probably quite reasonable for 99% of cases, as I've yet to see anyone use a Linux router in the core of their network.
Imagestream and Nbase-Xyplex do make heftier core-style Linux routers / layer 3 switches, but they aren't very widely deployed.
'STM Ring' is often used to describe fibre rings running the SDH protocol at layer 2 - it's SDH that provides the failover to the other direction.
SDH is the European equivalent of SONET. STM-x is the European equivalent of OC-x, which is just a measure of bandwidth.
I thought my K6-2/350 was quite fast enough - then I installed the latest bloatware, i.e. Mozilla, ...
VMware is also quite CPU hungry - it's fine for most things, running Windows on Linux on this hardware with 256 MB RAM, but it could still do with a speed boost when booting (which doesn't run at full speed).
This isn't a trend I particularly like, but it seems to be happening in the Linux world as the GUI applications get better...
Good points mostly, but you seem to be saying that ATM is the only way to go for such big pipes - this is far from the case, particularly for IP traffic, due to the problems of scaling SAR on ATM router interfaces (i.e. slicing packets into cells then reassembling them). See http://www.juniper.net/techcenter/techpapers/20000 4-03.html for some background.
Most large providers seem to be going for packet over SONET for IP traffic, and will ultimately go for MPLS alongside this. Eventually, SONET may well disappear or shrink as DWDM-native protection/failover becomes available. The good news is that the ATM cell tax is going away, and the cost of managing networks is going down (every node will be an IP or MPLS router, or an optical switch). See http://www.mplsrc.com for more on MPLS, it provides most of the benefits of ATM with much less complexity and overhead.
DWDM (dense wave-division multiplexing) lets you run many wavelengths simultaneously within a single fibre - probably this pipe is already using this, but DWDM will continue to improve, meaning that you can just upgrade the kit at each end to upgrade your bandwidth. 1 Terabit, here we come...
Opera is also very annoying in its insistence that standards conformance is more important than being able to view a page - it sometimes is unable to view the page at all, showing a blank screen.
Most of the time it works well (it is my main Windows browser, and is very fast indeed), but the standards conformance should be selectable - i.e. a button that says 'do your best and forget standards'.
Unfortunately the Opera people seem to think selectable standards conformance is not important. The IETFers disagree, saying 'be strict in what you send and liberal in what you accept' - since Opera is on the receiving end of HTML, a 'liberal' option would be far more useful, and in the long run would promote web standards by selling more copies of Opera.
With Windows NT on top of VMware 1.x on Linux, I had really atrocious mouse performance (many stops in mouse movement, etc) with a PS/2 mouse (the physical mouse).
When I switched to a serial mouse performance was fine, which I put down to the mouse sampling rate being lower. This may have been fixed, but I expect the load would be higher.
In fact, you'd probably get best performance from using serial for the virtual and physical mice.
Thanks, but I know about 'show all files' etc - it really was an SMB bug (most likely in Win95).
And make sure you do logical exports if possible, not just physical backups - it's a lot easier to spot and fix messed up data in a flat file.
Patents have a finite lifetime, as do copyrights (though they keep getting extended). However there's no way that software can go into the public domain just because it is not patented - typically the lifetime for patents is much less than that for copyrights (e.g. 20 years vs 50).
Interesting - presumably something like the Linuxbios work would make it possible to boot off a floppy that has an ext2 filesystem, or even FAT? Presumably FAT is the way to go, since it was originally designed for floppies and must have the bad block avoidance stuff built in.
Can ext2 remap bad blocks as well?
I've had the same problem with boot disks - on two NT machines and one Linux box, and about half a dozen floppies, I've been unable to make a Red Hat 6.2 bootnet.img boot disk. I fetched the .img file twice and did a cmp to make sure it was not corrupted, but I still can't get the damn thing to write to a floppy and not get corrupted - I suspect the floppies, as they were almost all very old and second hand.
Presumably what's happened is that the demand for floppies has dropped dramatically, so the disk vendors have had to cut costs equally dramatically to stay in business. Seems like quality has suffered in the process.
>>> I think any sort of copy operation performed through the GUI is automatically verified. This would explain why (especially floppies) copying via CLI is faster than drag'n'drop or "Send to A:"
This is not generally true, though perhaps some unusual GUIs do it. The overhead of verification is enough for most people to turn it off, even in the CLI world. The difference in speed is due to the overhead of GUI apps, no doubt - CLI copy tools evolved on much slower systems and are now blindingly fast.
In fact, when copying a full hard disk of files from a Win95 system to Windows NT via SMB via the Windows Explorer GUI, I was amazed to find a whole bunch of files missing. SMB had managed to quietly fail, with absolutely no errors, and of course the GUI had not noticed. (The problem went away when Win95 was the client to Samba on Linux - the bug was either in smbfs or in Win95's flaky server capabilities.)
You need to read up on IPv6 - the MAC address stays the same, when you move the device it either keeps its IP address (via Mobile IP, which IPv6 is quite good at) or gets a new one via various techniques (not just DHCP). I think ARP has gone away in IPv6, but there's something equivalent that generalises across most L2 protocols.