More Error Detection, Reliability, Ethernet

CS158a

Chris Pollett

Feb. 16, 2011

Outline

Error Detection
Stop and Wait Protocol
Sliding Window Protocol
Ethernet

More Error Detection

Last day, we looked at two error detection mechanisms two-dimensional parity (used by BISYNC) and checksums (PPP).
We begin today by looking at CRC codes (used by HDLC, DDCMP, Ethernet, and Token rings).

Cyclic Redundancy Check Codes

These are also known as polynomial codes.
A k-bit frame is viewed as specifying the coefficients of a degree k-1 polynomials.
For example 101 code 1x² +1x⁰.
Polynomials can be added mod 2, they can also be multiplied and divided.
In a CRC code, both sender can receiver agree on on a generator polynomial G(x) which has both its high and low order coefficient 1.
We assume the message m has length > deg(G)=r.
Let M(x) be the polynomial of the message.
To compute a checksum for a message we (1) Compute x^rM(x), (the bit sequence of this polynomial is that of M(x) shifted over r bits). (2) Divide x^rM(x) by G(x) to get a remainder R(x). (3) Send the coefficients of T(x) = x^rM(x)-R(x).

More on CRC codes.

Notice T(x) is divisible by G(x).
Suppose T(x)+E(x) arrives.
Then (T(x) +E(x))/G(x) = E(x)/G(x).
The only way an error is undetected is if this value is 0. If there was a single bit error then E(x)=xⁱ for some i which can't be divisible by G(x). So any single bit error will be detected.
If there are two errors then E(x)= xⁱ+ x^j where i>j. So E(x)= x^j(x^i-j +1). So this error will be detected provided that G(x) does not divide x^k+1 for any k up to i-j.
There are some low degree polynomials that will give this protection to very long frames. For instance, x¹⁵+ x¹⁴+1 does not divide x^k +1 for any k below 32768.
If E(X) contains an odd number of terms (hence errors), then it cannot have x+1 as a factor mod 2, so if x+1 is a factor of G(x) we can catch these errors.
To see this suppose E(x)=(x+1)Q(x) had an odd number of terms. Then E(1)=(1+1)Q(1) = 0 mod 2. On the other hand substituting 1 for an odd number of terms should give 1 mod 2.
CRC codes with r check bits will detect all burst errors of length ≤ r. Such an error would look like xⁱ(x^k +x^k-1 + .. +x⁰). If G(x) has a x⁰ term, it will not have an xⁱ factor, so if the degree of the parenthesized expression if less than G(x), the remainder won't be 0.
Ethernet uses the polynomial CRC-32 :=
x³² + x²⁶ + x²³+ x²²+ x¹⁶ + x¹² + x¹¹+ x¹⁰+ x⁸+ x⁷+ x⁵+ x⁴ + x² + x¹ +1

Reliable Transmission

So at this point let's assume we can detect if there is an error in our frame.
How can the sender know if the frame arrived to the receiver correctly?
This is usually accomplished using two mechanisms: acknowledgments (ACKs) and timeouts.
The receiver can send a special control frame (a frame without data but whose header contains control information) ACKing the receipt of the data frame.
If the sender does not receive the ACK frame within a timeout period it retransmits the frame.
This strategy of using ACKs and timeouts is called ARQ (automatic repeat request).
We next look at several ARQ algorithms.

Stop and Wait

In the stop and wait protocol, the sender sends a frame, then waits for an acknowledgement of the frame before transmitting the next frame. If the acknowledgment takes too long. Then the sender resends the frame.
There are four possible scenarios that could occur with this algorithm for a given frame:
1. The frame arrives okay and is acknowledged okay. This is the happy case.
2. The frame does not arrive okay. After the timeout period, the frame is re-sent and this time it is acknowledged. Even this is still pretty happy.
3. The frame arrives okay but the ACK frame is lost. The timeout then happens, the frame is re-sent and it is acknowledged correctly. This situation might cause problems (similar to the item 4 below).
4. The frame arrives okay but the ACK frame is sent but it arrives to the sender after the timeout period. So the sender has already re-sent the frame. This might be bad. How does the receiver know the re-sent frame is not the next frame?
To avoid the problem of situation 4, typically a 1-bit control sequence is used in the header of frames sent and in the acknowledgment frame. Each time the Sender sends, it adds 1 to this sequence number mod 2. The receiver's ACK frame should say in its header the sequence number being acknowledged.

The Drawback of Stop and Wait

The main problem with stop and wait is that it doesn't make efficient use of the bandwidth resources.
To see this suppose one had a 1.5Mbps link with a 45ms RTT.
Suppose the frame size is 1KB. Since only one frame can be sent per RTT, implies our effective bit rate is (1024 * 8)/.045 = 182 Kbps -- only 1/8 of the total channel bandwidth.
We would like somehow to be able to send 8 frames before we have to send an acknowledgment.

Sliding Window -- the Sender

In the sliding window protocol, the sender assigns a sequence number SeqNum to each frame. For now we'll assume that this number could be any natural number (even though it will eventually be implemented with some fixed number of bits).
The sender also has:
- a sender window size (SWS) -- the maximum number of unacknowledged frames that the sender can transmit. We will choose the SWS to try to keep the pipe as full as possible.
- a last acknowledgment received (LAR) -- the sequence number of the last frame acknowledged.
- a last frame sent (LFS) -- the sequence number of the last frame sent.
The sender maintains that LFS - LAR ≤ SWS.
The sender has a buffer of size SWS which could hold all of the frames which might not yet be acknowledged.
The sender has a timer for each frame that has not been acknowledged, and re-sends a frame if its timer goes off.
An acknowledgment from the receiver of a sequence number will now be a promise from the receiver that all smaller sequence numbers have been received. So when the sender gets an acknowledgement it checks if the number is between LAR and LFS, if it is, it sets LAR to this number -- all of the frames less than this are viewed as acknowledged.

Sliding Window -- the Receiver

Meanwhile, the receiver also maintains three variables:
- a receive window size (RWS) -- maximum number of out of order frame the receiver is willing to receive.
- a largest acceptable frame (LAF) -- the highest sequence number that the receiver is currently willing to accept.
- a last frame received (LFR) -- the sequence number of last frame received.
The receiver maintains that LAF - LFR ≤ RWS.
When a frame with SeqNum arrives, the receiver checks if SeqNum ≤ LFR or SeqNum ≥ LAF. If so the frame is out of the receiver's window and is discarded.
If the frame is in the receiver window, it is accepted.
The receiver ACKs the frame with sequence number SeqNumToAck, which denotes the largest sequence number not yet acknowledged, such that all frames less than or equal to it have been received.
The receiver then sets LFR =SeqNumToAck and LAF = LFR + RWS.

More Sliding Window

Suppose LFR=5, and RWS =4. So LAF = 9.
If frames 7 and 8 are received, they will be buffered because they are within the receiver window. However, no ACK needs to be sent yet because frame 6 has not yet arrived.
Frame 7 and 8 are said to be out of order.
When frame 6 arrives (it might have come later because it had a problem and had to be resent), LFR is set to 8 (this is also the sequence number ACK'd) and LAF is set to 12.
Suppose frame 6 had been lost, then a timeout would occur. The amount of data in transit decreases because the sender cannot advance his window. So in this situation the pipe might no longer be full.
One way to mitigate against this problem is when frame 7 arrives, the receiver sends a negative acknowledgement (NAK) for frame 6. This might get back to the sender before its timeout expires and so would allow the sender to re-send more quickly. This, of course, adds complexity to the receiver.
Another technique is to use selective acknowledgments. The receiver could acknowledge exactly those frames it receives, rather than the highest number frame received in order. This add considerable complexity though to the implementation.
The sending window size, SWS, is selected according to how many frames we want to have outstanding on the link at a given time. It is set to how many frames fit in a given delay * bandwidth product.
The RWS can be set to whatever the receiver wants. When RWS=1 the receiver does not buffer any out of order frames. When RWS=SWS, the receiver can buffer any of the frames the sender transmits. Setting RWS > SWS doesn't help since its impossible for more than SWS frames to arrive out of order.

Finite Sequence Numbers

Let's assume now that sequence numbers are bounded to values less than some number MaxSeqNum.
If the sequence number gets to MaxSeqNum - 1, the next sequence number is 0.
How big does MaxSeqNum have to be so that we don't have to worry about two different incarnations of the same sequence number?
Obviously, we want SWS < MaxSeqNum.
If RWS=1, then MaxSeqNum = SWS + 1 will work.
If SWS=RWS, SWS+1 does not work. Consider SWS=RWS=7, then if the sender sends 0..6 which are received by the receiver but all the ACKs are lost. Then the receiver is expecting frames 7,0..5. The sender timesout and resends 0..6 are some of these are confused for new frames.
It turns out in this case the correct answers is SWS < (MaxSeqNum +1 )/2

Frame Order and Flow Control

The sliding window protocol is one of the best-known computer networking algorithms. It actually can be used to support three different roles:

To deliver frames reliably across an unreliable link.
To preserve the order in which frame are transmitted.
To make sure that the receiver can slow down a sender who is transmitting too fast. (flow control)

Concurrent Logical Channels

The data link layer in the ARPANET used an interesting alternative to the sliding window protocol.
This protocol did not address order preservation or flow control.
ARPANET supported the ability to multiplex several logical channels onto a single point-to-point link and then ran stop-and-wait for each of these channels. This idea was referred to as the support for concurrent logical channels.
ARPANET supported 8 logical channels over each ground link and 16 over satellite links. Each channel had a 3 bit state, a boolean for whether the channel was busy, a 1-bit sequence number to use for the next frame, and the next sequence number to expect.
When one wanted to send a frame one used the first non-busy channel.

Ethernet

Ethernet is the most popular local area network (LAN) technology.
It was developed at Xerox PARC in the mid-1970s.
It makes use of a LAN technology known as carrier sense, multiple access with collision detection (CSMA/CD)
Multiple nodes can send and receive data over a shared Ethernet link. This is what multiple access means.
Carrier sense means that all nodes can distinguish between an idle link and if someone is talking (a busy link).
Collision detection means that a node listens as it transmits and can detect when a frame it is transmitting is interfered with by another frame from another node.
The technology that Ethernet uses was original worked out for an early packet radio network called Aloha developed at the University of Hawaii.
Both systems had to solve the problem of how to use a shared resource fairly and efficiently. i.e., we need to figure out who can transmit when.
DEC, Intel, and Xerox defined a 10 Mbps Ethernet standard in 1978, and this formed the basis for the IEEE 802.3 standard. This standard was later extended to include 100Mbps (Fast) Ethernet and 1000Mbps (Gigabit) Ethernet.
We will over the next class describe how Ethernet works.

Physical Properties of Ethernet

Originally, an Ethernet segment was implemented on a 50 ohm coaxial cable of up to 500m.
Hosts connected to such a segment by tapping into it; taps had to be at least 2.5m apart.
A transceiver, which was directly attached to the tap, detected when the line is idle and drove the signal when the host is transmitting.
The transceiver also received incoming signals.
It is connected to the Ethernet Adaptor of the given host.
Multiple segments could be joined by repeaters up to a maximum total reach of 2500m.
Bits on the Ethernet use Manchester encoding.
Signals on Ethernet are heard by all hosts attached to it.
Up 1,024 host may be attached to an Ethernet.

Variations on Physical Properties of Ethernet

More recent Ethernets replace the 50 ohm cable (also called 10Base 5 or thicknet cable) with a thinner cable known as 10Base2. Here 10 means 10Mbps, and 2 refers to 200m rather than 500m.
There is also 10BaseT Ethernet which uses twisted-pair wire and is restricted to 100m. This is what's used in Fast (100Mbps) Ethernet and in Gigabit Ethernet.
The typical configuration for 10Base2 and 10BaseT is to have several point-to-point segments coming out of a multiway repeater rather than use taps. This kind of repeater is called a hub.
Regardless of the set-up, all hosts can hear whatever anyone transmits on an Ethernet. So everyone on an Ethernet is competing for the shared resource. i.e., everyone is in the same collision domain.