Some, but not all.
Error control (e.g., V.42) and TCP/IP actually handle that (congestion) gracefully.
I would call this "dumb design" because it sacrifices speed in typical cases (bursty data) in order to simplify worst case operation.
Again, TCP/IP will actually handle that (congestion) gracefully. Otherwise, you could never interconnect a faster network to a slower network. See RFC
2001 and 2581.There were also USR, Hayes, and Multitech modems that would do that.
Sending flow control must be supported by the driver and the hardware, because they can't just assume that they can spew data as fast as USB 1.1 can go, since the wireless link may well have shifted down to a lower speed. Setting the max speed of the wireless to 11 Mbps doesn't solve the problem of a speed shift down to (say) 1 Mbps. I'd be willing to bet that receive flow control exists as well, since there can be cases when the host isn't able to receive data.
With all due respect, I think that's an exaggeration -- collisions are a fact of life with 802.11, and a fairly significant percentage of lost packets is normal. Regardless, TCP/IP will automatically throttle to whatever throughput is possible.
We'll just to disagree on this one.
It's not just a matter of packet loss.
Again, I disagree. Letting each protocol optimize throughput will almost certainly produce better results than crude throttling.
I have an ethernet adapter that connects to a parallel printer port. Parallel printer ports are way slower than 10 mbits yet it doesn't lose data.
Barry ===== Home page
Have something to add? Share your thoughts — no account required.
Ask the community — no account required