One of the major factors that affect TCP performance in 802.11 ad hoc networks is the unfairness in the MAC. Could someone please illustrate for me what this "unfairness" means?
In ad hoc networks, you usually are trying to do multihop routing. 802.11 CSMA/CA can manifest the "exposed terminal problem" in these situations. Consider a linear topology
... A <---> T <---> B ...
A and B are not in CSMA range. Suppose T is already transmitting a data stream to A. Now suppose a TCP stream starts getting routed through B. Because B CSMAs with A, it will essentially be locked out of the channel. The TCP connection being routed through B will eventually timeout.
Another possibility is the "hidden terminal problem". Consider the topology
A ---> X <--- B
A and B cannot CSMA. Suppose A and B each try to send a TCP stream to X. Because they cannot CSMA with each other, both win their respective channel contention rounds and transmit, only to have their frames collide at X. This can be solved to some extent with RTS/CTS. But in general, the reason for poor TCP performance in wireless environments has to do with the fact that TCP uses a dropped packet as a congestion signal, i.e., a TCP source will cut its window and there by drop its throughput. In wireless networks, dropped packets can be due to any number of transient things (e.g., collision, interference). A TCP source misinterprets these packet drops as a congestion signal and will throttle its send rate and underutilize the channel.
Another problem that can arise is due to the "capture effect". Again, consider
A ----> X <-------------B
Both A and B are in range of X, but B is farther away and thus has a lower received signal strength at X. Again, A and B cannot CSMA. In this case, X may "capture" the stronger transmitter A, i.e., its radio will decode A's frames but consider B's as noise (even though in the absence of A, X would go right ahead and decode B's frames). This sets up an unfair advantage for A if both are trying to route a TCP stream through X.
802.11's DCF also favors the last winner of the channel contention round. As a result, this gives a slight advantage to long-lived, bulk TCP transfers.
Note that all these problems affect all transport protocols, not just TCP. It's just that the way TCP is designed makes it react particularly poorly to these scenarios.
Related
Suppose we have 2 nodes, A and B, directly connected by Internet (we can ignore the underlyng network eg, routers, ISP etc).
We know RTT between nodes (80ms)
We know packet loss (0.1)
We know jitter (1ms)
We know bandwith, A=100/10mbps B=50/5mbps (first value is download, second is upload)
A sends a 1GB file to B by using the TCP protocol (with 64KB segment size).
How many times they need to exchange the file?
How many times it takes to do the same thing by using the UDP
protocol?
EDIT:
i guess the main difference in the calculation between UDP and TCP is that in TCP we need to wait for every packet to be sent before sending the next one. Or, in other words, we have to add in the delay calculation one RTT for every packet. Moreover, packetloss is not considered at all in UDP. I am not sure of what I'm sayng in this edit, so let me know if I'm wrong.
I would have a question regarding physical problem detection in a link with ping.
If we have a fiber or cable which has a problem and generate some CRC errors on the frame (visible with switch or router interface statistics), it's possible all ping pass because of the default small icmp packet size and statistically fewer possibilities of error. First, can you confirm this ?
Also, my second question, if I ping with a large size like 65000 bytes, one ping will generate approximately 65000 / 1500(mtu) = 43 frames, as ip framgents, then the statistics to get packet loss (because normally if one ip fragment is lost the entire ip packet is lost) with large ping is clearly higher ? Is this assumption is true ?
The global question is, with large ping, could we easier detect a physical problem on a link ?
A link problem is a layer 1 or 2 problem. ping is a layer 3 tool, if you use it for diagnosis you might get completely unexpected results. Port counters are much more precise in diagnosing link problems.
That said, it's quite possible that packet loss for small ping packets is low while real traffic is impacted more severely.
In addition to cable problems - that you'll need to repair - and a statistically random loss of packets there are also some configuration problems that can lead to CRC errors.
Most common in 10/100 Mbit networks is a duplex mismatch where one side uses half-duplex (HDX) transmission with CSMA/CD while the other one uses full-duplex (FDX) - once real data is transmitted, the HDX side will detect collisions, late collisions and possibly jabber while the FDX side will detect FCS errors. Throughput is very low, put ping with its low bandwidth usually works.
Duplex mismatches happen most often when one side is forced to full duplex, thus deactivating auto-negotiation and the other side defaults to half duplex.
I have been studying a book on Computer Networking (this is not a homework question)
One of the questions compares ACK and NAK based data transfer protocols, with the emphasis being that for a NAK based protocol, packet loss can for packet x can be detected by the received when the (x + 1)th packet is received.
However, my issue is that what happens if the NAK sent by the receiver is lost before it gets to the sender? The sender will not be aware of errors and will not retransmit. Furthermore, what if the packet is the last one in the sequence? (there is no subsequent packet to test with)
I do not see how a NAK-only protocol can be reliable (delivers each packet in the correct order)
I suspect that the theoretical context described in the book assumes an infinite stream of packets and ignores conditions like the channel becoming completely disabled. In practice, there are other constructs defined as part of the ACK/NAK protocol or left up to higher or lower layer layer protocols to deal with. For instance, a physical layer would provide indications like "the channel is broken", and perhaps a protocol above sends/receives "end-of-stream" packets, with a timer detect the case where the NAK for the last packet is lost. These are just hypothetical examples, but are the types of things real-life protocols do.
I do not see how a NAK-only protocol can be reliable (delivers each
packet in the correct order)
I'm sure the book is implying there is some sort of mechanism for identifying packets in order. Otherwise, there would be no way for the receiver to indicate which packet it is NAK'ing, i.e., most protocols use a sequence number in each packet/ack/nak.
A NAK-only protocol can achieve reliability by having the receiver start a timer when sending a NAK and retransmit the NAK when the timer times out before the missing packet was retransmitted.
TCP slow start came about in a time when the Internet began experiencing "congestion collapses". The anecdotal example from Van Jacobson and Michael Karels paper goes:
During this period, the data throughput from LBL to UC Berkeley (sites separated
by 400 yards and two IMP hops) dropped from 32 Kbps to 40 bps.
The congestion problem is often described as being caused by the transition from a high-speed link to a slow-speed link, and packet build up/dropping at the buffer at this bottleneck.
What I'm trying to understand is how such a build up would cause a drop in end-to-end throughput, as opposed to simply causing superfluous activity/retransmits on the high-speed portion of the link leading into the full buffer. As an example, consider the following network:
fast slow fast
A ======== B -------- C ======== D
A and D are the endpoints and B and C are the packet buffers at a transition from a high speed to low speed network. So e.g. the link between A/B and C/D is 10Mbps, and link between B/C is 56Kbps. Now if A transmits a large (let's say theoretically infinite) message to D, what I'm trying to understand is why it would take it any longer to get through if it just hammered the TCP connection with data versus adapting to the slower link speed in the middle of the connection. I'm envisaging B as just being some thing whose buffer drains at a fixed rate of 56Kbps, regardless of how heavily its buffer is being hammered by A, and regardless of how many packets it has to discard because of a full buffer. So if A is always keeping B's buffer full (or overfull as may be the case), and B is always transmitting at it's maximum rate of 56Kbps, how would the throughput get any better by using slow-start instead?
The only thing I could think of was if the same packets D had already received were having to be retransmitted over the slow B/C link under congestion, and this was blocking new packets. But wouldn't D have typically ACK'd any packets it had received, so retransmitted packets should be mostly those which legitimately hadn't been received by D because they were dropped at B's buffer?
Remember that networks involve sharing resources between multiple computers. Very simplistically, slow start is required to avoid router buffer exhaustion by a small number of TCP sessions (in your diagram, this is most likely at points B and C)
From RFC 2001, Section 1:
Old TCPs would start a connection with the sender injecting multiple
segments into the network, up to the window size advertised by the
receiver. While this is OK when the two hosts are on the same LAN,
if there are routers and slower links between the sender and the
receiver, problems can arise. Some intermediate router must queue
the packets, and it's possible for that router to run out of space.
[2] shows how this naive approach can reduce the throughput of a TCP
connection drastically.
...
[2] V. Jacobson, "Congestion Avoidance and Control," Computer
Communication Review, vol. 18, no. 4, pp. 314-329, Aug. 1988.
ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.
Routers must have finite buffers. The larger a speed mismatch between links is, the greater the chance of buffer exhaustion without slow start. After you have buffer exhaustion, your average TCP throughput will go down because buffering increases TCP's ability to utilize links (preventing unnecessary drops for instantaneous link saturation).
Note that RFC 2001 above has been superseded by RFC 5681; however, RFC 2001 offers a more quotable answer to your question.
From your OP...
Now if A transmits a large (let's say theoretically infinite) message to D, what I'm trying to understand is why it would take it any longer to get through if it just hammered the TCP connection with data versus adapting to the slower link speed in the middle of the connection.
First, there is no such thing as an infinite message in TCP. TCP was limited by the initial window size before slow-start came along.
So, let's say the initial TCP segment was 64KB long. If the entire TCP segment fills the router's tx buffer at B, TCP utilizes less of the link over time due to dynamics involved with packet loss, ACKs and TCP back-off. Let's look at individual situations:
B's tx_buffer < 64KB: You automatically lost time for retransmissions because A's TCP is sending faster than B can dequeue packets
B's tx_buffer >= 64KB: As long as A is the only station transmitting, no negative effects (as long as D is ACK-ing correctly); however, if there are multiple hosts transmitting on A's LAN trying to transit across the 56K link, there are probably problems because it takes 200 milliseconds to dequeue a single 1500 byte packet at 56K. If you have 44 1500-byte packets from A's 64KB initial window (44*1460=64KB; you only get 1460 bytes of TCP payload), the router has a saturated link for almost 9 seconds handling A's traffic.
The second situation is neither fair nor wise. TCP backs off when it sees any packet loss... multiple hosts sharing a single link must use slow start to keep the situation sane.
BTW, I have never seen a router with 9 seconds of buffering on an interface. No user would tolerate that kind of latency. Most routers have about 1-2 seconds max, and that was years ago at T-1 speeds. For a number of reasons, buffers today are even smaller.
Can a machine send n network messages/packets (to n destinations), simultaneously? Is there a upper bound on level of parallelism and what affects network's parallelism.
More specific, say there are 2 packets and four event, s1, r1 and s2, r2 denotes send/receive packet 1 and send/receive packet 2. When we send asynchronously (like s1, s2...r1,r2) and synchronously (s1...r1,s2...,r2), does it matter? Could total latency be shorten in the case of asynchronous send.
Yes, they can. A NIC just transmits the frames the driver tells it to, and does it as soon as it can. NICs don't care about destinations.
Higher layers (e.g: TCP) are responsible for retransmissions, and have their own buffering. NICs usually can have several frames ready to be sent, but they stay little time in the NIC, as soon as the medium is free, and the NIC has transmitted a frame without collisions, it can take another frame ready for transmission.
You basically have three choices:
Point to point
Multicast
Broadcast
A point to point message goes from one source to one destination.
A multicast message goes from the source, to the router, and from there gets distributed to the multiple recipients. There are some relatively intelligent switches (usually called "layer 2+" or something on that order) that can handle multicasting as well, but your average "garden variety" switch usually can't/won't handle it.
A broadcast goes from the source to everything else on the local subnet. There are a cople of ways this can be done. Probably the most common is to send to the address 255.255.255.255. Broadcasting is supported directly by Ethernet, which has a "broadcast" MAC address of FF:FF:FF:FF:FF:FF.
Note that IPv6 no longer supports broadcasting, but does have an "all hosts" multicast group that's vaguely similar.