802.11* was designed for indoor use, so the MAC layer depends on all stations hearing each other in order to arbitrate access to the shared medium.
As a fall-back they also included RTS/CTS mode. But RTS/CTS is rather suboptimal - some sort of polling or token mode would work better for outdoor wireless data comm.
So these guys implemented a token mode for controlling the clients' access to the wireless medium. Hack? Sure. Would it be better to implement it in the radio firmware? Sure. But it works!:)
You could have this problem, in theory, on an unswitched Ethernet network with a mixture of 10 Mbps- and 100 Mbps-capable hosts. The problem is that the bandwidth is shared, but not equally, because it just takes some users longer to transmit.
Kind of. Except that you can't have both 10Mbps and 100Mbps NICs connected to a hub. They all have to use the same modulation speed, so the hub is locked at either 10 or 100.
But the theory is sound - if you have a shared medium that supports different modulation speeds and the stations transmitting on the medium have equal chance of sending a packet, the busy station transmitting with slowest modulation will dictate the maximum packet rate of all stations.
Basically, the way CSMA/CA works, when I want to transmit, I send a jamming signal. If I don't receive a jamming signal in some small amount of time, I can assume with some degree of safety that no-one else is trying to transmit at the same time.
Hmm? That's roughly how Ethernet works (and it's/CD and not/CA).
With 802.11* communication, you typically transmit at ~20dBm and receive at ~-60dBm. The difference in signal strength is ~10^8, so it is pretty much impossible to detect someone else transmitting at the same time. Instead, 802.11* use Collission Avoidance. In short - listen before transmit, and explicit ACK.
The worst case scenario will end up with simple alternation: you send a packet, the other person sends a packet; you send a packet, the other person sends a packet; etc.
Yup. That's pretty much how the 802.11 MAC layer works if several wireless stations are trying to communicate at the same time. All stations have roughly the same chance of sending a packet, and the client @1Mbps will use 11 times more air time per packet than a client @11Mbps.
Anyway.. I don't quite understand why you have to be a researcher to 'discover' that a client that is associated at 1Mbps can drag an entire 802.11 segment down the drain. This has been known for a long time.
Software patents are good on Mondays, Wednesdays, and Fridays.
Well. This patent might actally be good. And the only reason for that is that software patents are bad.
You see, if InterTrust's patents are valid then most users of DRM would have to pay them a license fee. Make the license fee high enough and it suddenly becomes less compelling for software and media companies to encumber their products with DRM technology.
Software patents are bad in the sense that landmines are bad. But the irony here is that this particular landmine is sitting under the feet of our enemies. #include <obligatory quote about poetic justice>
3) The congestion control algorithms that are in use now (and are used by FAST) work by having congested routers set bits in the ACK packets going back to the source. When the sender sees these panic bits, it slows down.
The fact that the CalTech group got a lot of improvement from their implementation is good real-world evidence that your analysis is probably off, since they don't halve their TX rate and they achieved significantly better throughput.
What I'd like to know is where they did this real-world test. On a connection between two universities on Internet2 with wide fiber links, I can understand that they see a considerable perfomance gain. However, I'd also like to see tests done through consumer grade DSL or cable connections where the ISP typically use deep buffers.
It is not UDP, but as Microsoft and Disney want to use it for Streaming Video they should use UDP. Every Broadband Video Stream i know uses UDP as it is not necessary that the connection is 100% reliable. So why could they want to use TCP???
As you mention, TCP isn't exactly a good match for streaming applications. UDP is one option, but the problem with UDP is that you have no standard rate/congestion control - each application/protocol on top of UDP has to reinvent it. UDP is okay'ish as long as not too many people use it. If the amount of streaming on the Internet increases, you need some sort of congestion control to make sure that the streaming traffic doesn't saturate the links.
What is needed is a new standard protocol which behaves like UDP + rate/congestion control.
I'm not saying all, but the control connection in FTP, HTTP, IRC, and many others use the same basic methods as telnet, because, hey, why reinvent the wheel?
Human readable commands over a TCP connection isn't telnet. However, because many Internet protocols use a plain text control connection, you can use a telnet client to talk to a FTP/HTTP/IRC/SMTP/POP3/NNTP/whatever server.
intel x86s? i wouldn't be suprised to see stuff like the i960s or whatever... but x86?
It is not uncommon for the lower end routers to contain an x86 or an embedded version of the Moto 68k or PPC. You also find general CPUs in higher end gear, but they also contain special ASICS handling (most of) the routing and forwarding work.
The venerable Cisco 760/770 series contained an 80386.
The Cisco 1600 series contained an embedded version of the Motorola 68020 - 68360@33MHz.
The Cisco 800 series contains an embedded version of the Motorola PPC.
Laugh all you want, but this is what's beautiful about life: My rights don't have to be defined anywhere.
As long as you don't sign a contract or license, that DVD in your hand is your property. You can do whatever you like with it, including putting it in the microwave to watch the funny sparkles.
As for the content of the DVD - that's a matter of copyright law. Nowhere in the US copyright law does it say that it is illegal to watch the contents of a DVD with whatever tools or means you deem necessary (well, except for that braindead anticircumvention DMCA thingie).
What I really find frustrating, is that some people have been exposed to EULAs for so long that they actually start to believe that they are legally binding contracts. They're not.
Er. It depends what you mean by circuit-switched. When you want to talk to someone via ATM, you need to establish a virtual circuit to them, a process that involves each ATM switch between you and the other VC endpoint. This sets up the path the ATM packets in that VC will take through the network (and ATM packets are *small* - 53 bytes).
True. I guess we're just arguing semantics.:-)
Anyway, in my book a virtual circuit running over a packet switched network is an emulated circuit over a packet network.
ATM cells are small, and ATM is specifically designed from the ground up to facilitate virtual circuits. No argument there. But it is still a packet switched network, imho.
Compare this with IP, etc - the routers don't (or at least shouldn't have to) care about anything beyond the destination header in the packet, something that shouldn't be modified en-route. TCP doesn't require the intervening routers to know about it.
IP is best-effort, TCP is a session protocol on top of IP. None of them have any comprehensive support for the kind of QoS you need for voice connections.
However, you can do pretty much the same thing for IP traffic by using MPLS, 802.1p and 802.1Q.
They don't actually say they own the code (in this excerpt), but rather, that they have licensed it to IBM. As I'm sure you know, there are often agreements made that allow corporations to sublicense works; although Novell owns the code itself, if they granted SCO the right to license it (as they apparently have), and SCO licensed it to IBM (as they apparently have), IBM is still responsible for using it legally.
Good point. But this would also make it a pure license/contract issue between SCO and IBM - SCO does evidently not hold copyright or patent rights to the code, so they can't go after SuSE or any other GNU/Linux distributor, vendor or user.
If IBM broke the license, SCO can get damages. But unless I'm missing something it seems like they can not go after any other party for using or distributing said code. That makes the threat letter a bit puzzling, to say the least.
So when you use a dail-in account with a sprint-network, everything will be converted to packages first, then send to your provider over the internet, converted back to analog, converted to digital and then you have your connection on the internet?
Yup. All reasonably modern telcos today have digital exchanges. Telenor, the old telco monopoly in Norway, started the change in 1986 and the last analog exchange was replaced in 1997.
Modem - Analog line - Local telco exchange - digital through telco network(s) - Local telco exchange - Analog line - Modem
You seem to be labouring under the mistaken impression that digital == packet-switched and circuit-switched == analogue.
Circuit-switched is things like ATM and TDM (over E1s, etc): you establish a "circuit" to who you want to communicate with (an expensive operation), and then talk over that.
Hmm. Doesn't ATM do "virtual circuits" over a packet switched medium? Not that different from a TCP session, except that an ATM VC can provide guaranteed bandwidth and latency.
In my book "circuit-switched" == dedicated line from end to end, doesn't matter whether the signal is analog or digital. With that definition, ATM is doing virtual circuit switching over a packet switched network.
You can have QoS on a packet switched network to...
If the physical/link layer supports it.
The telco-inspired technologies typically have heavy QoS support (ATM, HiperLAN2, etc), while it is more or less absent in LAN/Internet technologies (Ethernet, 802.11).
The Internet is best-effort, and the technology isn't really suited to do end-to-end guaranteed bandwidth/latency.
The IP argument for no Linux drivers seems a little odd.
A lot of the hard stuff presumably (hard to verify this without specs) happens in the driver instead of in the hardware. So by releasing source they think that their competitors get an upper hand.
I believe the 22Mbps cards are merely full duplex.
802.11/b/g/h is half duplex. Transmit and receive is on the same channel.
What they did with the 22Mbps part, was adding an additional modulation to the 802.11b spec. Works OK, but it's not a standard - and Linux support is abysmal.:-/
Slashdot Mirror
1. Isn't this what RTS/CTS is for?
:)
Except that RTS/CTS doesn't work well enough.
802.11* was designed for indoor use, so the MAC layer depends on all stations hearing each other in order to arbitrate access to the shared medium.
As a fall-back they also included RTS/CTS mode. But RTS/CTS is rather suboptimal - some sort of polling or token mode would work better for outdoor wireless data comm.
So these guys implemented a token mode for controlling the clients' access to the wireless medium. Hack? Sure. Would it be better to implement it in the radio firmware? Sure. But it works!
You could have this problem, in theory, on an unswitched Ethernet network with a mixture of 10 Mbps- and 100 Mbps-capable hosts. The problem is that the bandwidth is shared, but not equally, because it just takes some users longer to transmit.
Kind of. Except that you can't have both 10Mbps and 100Mbps NICs connected to a hub. They all have to use the same modulation speed, so the hub is locked at either 10 or 100.
But the theory is sound - if you have a shared medium that supports different modulation speeds and the stations transmitting on the medium have equal chance of sending a packet, the busy station transmitting with slowest modulation will dictate the maximum packet rate of all stations.
Basically, the way CSMA/CA works, when I want to transmit, I send a jamming signal. If I don't receive a jamming signal in some small amount of time, I can assume with some degree of safety that no-one else is trying to transmit at the same time.
/CD and not /CA).
Hmm? That's roughly how Ethernet works (and it's
With 802.11* communication, you typically transmit at ~20dBm and receive at ~-60dBm. The difference in signal strength is ~10^8, so it is pretty much impossible to detect someone else transmitting at the same time. Instead, 802.11* use Collission Avoidance. In short - listen before transmit, and explicit ACK.
The worst case scenario will end up with simple alternation: you send a packet, the other person sends a packet; you send a packet, the other person sends a packet; etc.
Yup. That's pretty much how the 802.11 MAC layer works if several wireless stations are trying to communicate at the same time. All stations have roughly the same chance of sending a packet, and the client @1Mbps will use 11 times more air time per packet than a client @11Mbps.
Anyway.. I don't quite understand why you have to be a researcher to 'discover' that a client that is associated at 1Mbps can drag an entire 802.11 segment down the drain. This has been known for a long time.
an EU directive makes disassembling and reverse engineering explicitly illegal.
Which directive? According to directive 91/250/EEC, reverse engineering is expliclitly legal in EU/EEC.
Do these people not know you can reject cookies with your browser?
Yes, they do. But they also know that it is often hard for the user to know for which purposes the cookies are used.
This is not an anti-cookie law. This is a law that requires the website to tell the user what the cookies are used for.
Software patents are good on Mondays, Wednesdays, and Fridays.
Well. This patent might actally be good. And the only reason for that is that software patents are bad.
You see, if InterTrust's patents are valid then most users of DRM would have to pay them a license fee. Make the license fee high enough and it suddenly becomes less compelling for software and media companies to encumber their products with DRM technology.
Software patents are bad in the sense that landmines are bad. But the irony here is that this particular landmine is sitting under the feet of our enemies. #include <obligatory quote about poetic justice>
Mozilla is one of the 'pillars' of OSS software, along with GCC, the Linux kernel, KDE, GNOME, and Apache (I'm probably forgetting some too).
Glibc, XFree and Samba.
3) The congestion control algorithms that are in use now (and are used by FAST) work by having congested routers set bits in the ACK packets going back to the source. When the sender sees these panic bits, it slows down.
Is this ECN, or is that a separate feature?
The fact that the CalTech group got a lot of improvement from their implementation is good real-world evidence that your analysis is probably off, since they don't halve their TX rate and they achieved significantly better throughput.
What I'd like to know is where they did this real-world test. On a connection between two universities on Internet2 with wide fiber links, I can understand that they see a considerable perfomance gain. However, I'd also like to see tests done through consumer grade DSL or cable connections where the ISP typically use deep buffers.
It is not UDP, but as Microsoft and Disney want to use it for Streaming Video they should use UDP. Every Broadband Video Stream i know uses UDP as it is not necessary that the connection is 100% reliable. So why could they want to use TCP???
As you mention, TCP isn't exactly a good match for streaming applications. UDP is one option, but the problem with UDP is that you have no standard rate/congestion control - each application/protocol on top of UDP has to reinvent it. UDP is okay'ish as long as not too many people use it. If the amount of streaming on the Internet increases, you need some sort of congestion control to make sure that the streaming traffic doesn't saturate the links.
What is needed is a new standard protocol which behaves like UDP + rate/congestion control.
Oh, and for "statistics" read "numbers that I pulled out of my ass
When a techie makes a guess, it is often called a SWAG - Scientific Wild Assed Guess.
I wonder what the correct term is when BSA makes up statistics. Perhaps PHB-WAG?
but it's also the only way I know of to limit inbound internet bandwidth... any other ideas?
Won't delaying ACKs have the same effect?
I think that products like Packeteer does a lot of stuff to "help" TCP rate control - playing with window sizes, delaying ACKs, sending ECN.
If you control one computer on each side of a firewall/gateway, you will almost always find a way to get through.
Generic HTTP tunnels have been available for some time. Some people are even selling them.
I'm not saying all, but the control connection in FTP, HTTP, IRC, and many others use the same basic methods as telnet, because, hey, why reinvent the wheel?
Human readable commands over a TCP connection isn't telnet. However, because many Internet protocols use a plain text control connection, you can use a telnet client to talk to a FTP/HTTP/IRC/SMTP/POP3/NNTP/whatever server.
intel x86s? i wouldn't be suprised to see stuff like the i960s or whatever ... but x86?
It is not uncommon for the lower end routers to contain an x86 or an embedded version of the Moto 68k or PPC. You also find general CPUs in higher end gear, but they also contain special ASICS handling (most of) the routing and forwarding work.
The venerable Cisco 760/770 series contained an 80386.
The Cisco 1600 series contained an embedded version of the Motorola 68020 - 68360@33MHz.
The Cisco 800 series contains an embedded version of the Motorola PPC.
Laugh all you want, but this is what's beautiful about life: My rights don't have to be defined anywhere.
As long as you don't sign a contract or license, that DVD in your hand is your property. You can do whatever you like with it, including putting it in the microwave to watch the funny sparkles.
As for the content of the DVD - that's a matter of copyright law. Nowhere in the US copyright law does it say that it is illegal to watch the contents of a DVD with whatever tools or means you deem necessary (well, except for that braindead anticircumvention DMCA thingie).
What I really find frustrating, is that some people have been exposed to EULAs for so long that they actually start to believe that they are legally binding contracts. They're not.
Er. It depends what you mean by circuit-switched. When you want to talk to someone via ATM, you need to establish a virtual circuit to them, a process that involves each ATM switch between you and the other VC endpoint. This sets up the path the ATM packets in that VC will take through the network (and ATM packets are *small* - 53 bytes).
:-)
True. I guess we're just arguing semantics.
Anyway, in my book a virtual circuit running over a packet switched network is an emulated circuit over a packet network.
ATM cells are small, and ATM is specifically designed from the ground up to facilitate virtual circuits. No argument there. But it is still a packet switched network, imho.
Compare this with IP, etc - the routers don't (or at least shouldn't have to) care about anything beyond the destination header in the packet, something that shouldn't be modified en-route. TCP doesn't require the intervening routers to know about it.
IP is best-effort, TCP is a session protocol on top of IP. None of them have any comprehensive support for the kind of QoS you need for voice connections.
However, you can do pretty much the same thing for IP traffic by using MPLS, 802.1p and 802.1Q.
They don't actually say they own the code (in this excerpt), but rather, that they have licensed it to IBM. As I'm sure you know, there are often agreements made that allow corporations to sublicense works; although Novell owns the code itself, if they granted SCO the right to license it (as they apparently have), and SCO licensed it to IBM (as they apparently have), IBM is still responsible for using it legally.
Good point. But this would also make it a pure license/contract issue between SCO and IBM - SCO does evidently not hold copyright or patent rights to the code, so they can't go after SuSE or any other GNU/Linux distributor, vendor or user.
If IBM broke the license, SCO can get damages. But unless I'm missing something it seems like they can not go after any other party for using or distributing said code. That makes the threat letter a bit puzzling, to say the least.
So when you use a dail-in account with a sprint-network, everything will be converted to packages first, then send to your provider over the internet, converted back to analog, converted to digital and then you have your connection on the internet?
Yup. All reasonably modern telcos today have digital exchanges. Telenor, the old telco monopoly in Norway, started the change in 1986 and the last analog exchange was replaced in 1997.
Modem - Analog line - Local telco exchange - digital through telco network(s) - Local telco exchange - Analog line - Modem
You seem to be labouring under the mistaken impression that digital == packet-switched and circuit-switched == analogue.
Circuit-switched is things like ATM and TDM (over E1s, etc): you establish a "circuit" to who you want to communicate with (an expensive operation), and then talk over that.
Hmm. Doesn't ATM do "virtual circuits" over a packet switched medium? Not that different from a TCP session, except that an ATM VC can provide guaranteed bandwidth and latency.
In my book "circuit-switched" == dedicated line from end to end, doesn't matter whether the signal is analog or digital. With that definition, ATM is doing virtual circuit switching over a packet switched network.
You can have QoS on a packet switched network to...
If the physical/link layer supports it.
The telco-inspired technologies typically have heavy QoS support (ATM, HiperLAN2, etc), while it is more or less absent in LAN/Internet technologies (Ethernet, 802.11).
The Internet is best-effort, and the technology isn't really suited to do end-to-end guaranteed bandwidth/latency.
I'd like to know why IBM hasn't counter-sued SCO yet.
Ditto. I'm a bit surprised that IBM hasn't carped bombed SCO yet with their huge defensive patent portfolio.
What is it with graphics card demos and fairies?
Yeah. Bring back the teapots!
The IP argument for no Linux drivers seems a little odd.
A lot of the hard stuff presumably (hard to verify this without specs) happens in the driver instead of in the hardware. So by releasing source they think that their competitors get an upper hand.
I believe the 22Mbps cards are merely full duplex.
:-/
802.11/b/g/h is half duplex. Transmit and receive is on the same channel.
What they did with the 22Mbps part, was adding an additional modulation to the 802.11b spec. Works OK, but it's not a standard - and Linux support is abysmal.