Comp 343/443    

Fall 2011, LT 412, Tuesday 4:15-6:45
Sept 13

Read:
    Ch 1, sections 1,2,3 and 5 (section 4 is about network programming in C; we'll skip that for now)
    Ch 2, sections 1, 2, 3, 5

Homework 1

Due Thursday, Sept 22

Numbering is (5th edition / 4th edition). I corrected the 5th edition numbering after class on Sept 13.

Chapter 1:
Chapter 2:
Additional problem [From Stallings]: Suppose we have nodes A and B connected through a router R as follows: A------R-----B. Sliding windows with SWS=3 is done on the A-R link (not end-to-end). Stop-and-wait is done on the R-B link.

The propagation delay for the A-R link is 20 ms, and for the R-B link is 5 ms. The A-R bandwidth is 10 ms / data-packet; ACK packets are of negligible size.

What bandwidth on the R-B link is necessary so that the long-term throughput on both links is equal?

Sliding Windows ;  §2.5, P&D 

2.5: stop-and-wait versus sliding windows
Four stop-and-wait scenarios
                    (a) Frame sent / ACKreceived
                    (b) Frame sent / lost ACK; Frame retransmitted
                    (c) Lost Frame, retransmitted, one ACK sent
                    (d) late ACK (arriving after Frame is retransmitted)
                     
Either side can implement timeouts, retransmitting their previous Data or Ack if nothing new is received. Either side can also retransmit on receipt of a duplicate (ie old) packet from the other side. We'll call these strategies retransmit-on-timeout and retransmit-on-duplicate.

At least one side must implement retransmit-on-timeout (otherwise a lost packet would lead to deadlock!)
At least the other side (maybe both) must then implement retransmit-on-duplicate.
Usual procedure:
    data sender: implements retransmit-on-timeout
    data receiver: implements retransmit-on-duplicate
sorcerers' apprentice bug  (both sides retransmit on duplicate). We also need something else to trigger the effect. Having a data packet be duplicated (or resent before the ACK arrived) is one way. Another is if the receiver also implements retransmit-on-timeout, a data packet is lost, and the retransmission crosses on the wire with the previous ACK.

See Disney's Fantasia,  http://www.youtube.com/watch?v=XChxLGnIwCU, around T= 5:35

For stop-and-wait, note that the first packet and last packet require special handling. The first packet presupposes some connection set-up has occurred; in the real-world stop-and-wait TFTP protocol, the first packet also sets the data-source port number and thus duplication can be confusing to the receiver. Loss of the final packet is a problem for any protocol, as by definition the final packet is not acknowledged.

Sliding Windows                

"Ladder" diagram of SWS=4 , with RTT = 4 * (packet_transmit_time)

sliding windows basic ideas:
      
Most sliding-windows implementations use cumulative ACKs. This means that ACK[5] acknowledges not only DATA[5] but also DATA[1] through DATA[4]. A consequence is that lost ACKs are seldom a problem, but another consequence is that if DATA[4] is lost but DATA[5] is received, then the latter cannot be acknowledged directly.

sliding-windows state variables
sender:
receiver:
Note that, in the treatment in Chapter 2, Peterson & Davie assume that sliding windows is operating over a single link. As such, packets can not be reordered. Once switches are introduced, however, life becomes more complicated. While there is no reason not to do link-level sliding-windows for throughput maximization, the End-to-End Principle suggests that error recovery be done end-to-end, and lost-packet recovery has quite a bit of overlap with sliding windows. (The End-to-End Principle is not universally agreed on.)

slow sender v slow router
bandwidth×delay

Four regions of sender line:
        x <=LAR, LAR<x<=LFS, LFS<x<=LAR+SWS, LAR+SWS<x

Selective ACKs (SACKs)

Finite sequence numbers

Flow control & slow receiver
    ACK = "ready to receive"
    ACK = "maybe not ready"
    TCP solution
              

Loss recovery under sliding windows

Diagrams when a single packet is lost. Note that, if SWS=4 and packet 5 is lost, then packets 6, 7, and 8 may have been received. For this reason (and because losses are usually associated with congestion, when we do not wish to overburden the network), we will retransmit only the first lost packet, eg packet 5. If packets 6, 7, and 8 are also lost, then we will receive ACK(5). However, if packets 6-8 made it through after all, then we will receive back ACK(8), and so the sender then knows 6-8 do not need retransmission and that the next packet we will send is packet 9.

Simple fixed-window-size analysis.

                
My example:
                     
                    A----R1----R2----R3----R4----B
                    
In the backward B->A direction, all connections are infinitely fast (perhaps because ACK packets are negligibly small?). In the A->B direction, the A->R1 link is infinitely fast, but the other four each have a bandwidth of 1 packet/second. This makes the R1->R2 link the "bottleneck link" (it has the minimum bandwidth, and although there's a tie for the minimum this link is the first such one encountered)

The "path bandwidth" is the minimum bandwidth.
                
Alternative example:
                        C----S1----S2----D
with the following assumptions: C--S1 link is infinitely fast (zero delay), S1->S2, S2->D each take 1.0 sec bandwidth delay (so two packets take 2.0 sec, per link, etc), and ACKs have the same delay in the reverse direction.

Note: what happens if we replace bandwidth delay by propagation delay?
                        
In both scenarios:
                        no-load RTT = 4.0 sec
                        Bandwidth = 1.0 packet/sec (= min link bandwidth)
                
We assume a single connection is made; ie there is no competition.
Bandwidth × Delay here is 4 packets (1 packet/sec × 4 sec RTT)
                
Case 1: SWS = 2
            so SWS < bandwidth×delay (delay = RTT): 
                     less than 100% utilization
                      delay is constant as SWS changes (eg to 1 or 3); this is the "base" rtt or "no-load" RTT
                                throughput is proportional to SWS
                       When SWS= 2, throughput = 2 packets /4 sec = 2/4 = 1/2 packet/sec
                        During each second, two of the routers R1-R4 are idle
                        RTT_actual = 4 sec

time
 A sends
 R1 queues
 R1 sends
 R2 sends
 R3 sends
 R4 sends
 B ACKs
0
 1,2
 2
 1



1

2
 1


2


2
 1

3



2
 1
4
 3
3

2
 1
5
 4
4
 3

2
6


4
 3

7



4
 3
8
 5



4
 3
               

Note the brief pile-up at R1 (the bottleneck link!) on startup. However, in the steady state, there is no queuing. (That changes below in case 3.) Real sliding-windows protocols generally have some way of minimizing this "initial pileup".

Case 2: SWS = 4
                 When SWS=4, throughput = 1 packet/sec, RTT_actual =4,
                 and each second all four bottleneck links are busy.
                 Note that throughput = bottleneck-link bandwidth, so this is the best possible throughput.
      

time
 A sends
 R1 queues
 R1 sends
 R2 sends
 R3 sends
 R4 sends
 B ACKs
0
 1,2,3,4
 2,3,4
 1



1
3,4
 2
 1


2
4
 3
 2
 1

3
empty
 4
 3
 2
 1
4
 5
 empty
 5
 4
 3
 2
 1
5
 6
 empty
 6
 5
 4
 3
 2
6
 7
7
 6
 5
 4
 3
7
 8
8
 7
 6
 5
 4
8


8
 7
 6
 5
               
Note that the RTT is 4.0 seconds for each packet, and that after T=2 the queue is always empty. For example, at T=4, R1 has just finished sending packet 4 as packet 5 arrives from A; R1 can begin sending packet 5 immediately.

                                       
Case 3: SWS = 6 

time
 A sends
 R1 queues
 R1 sends
 R2 sends
 R3 sends
 R4 sends
 B ACKs
0
 1,2,3,4,5,6
 2,3,4,5,6
 1



1
3,4,5,6
 2
 1


2
4,5,6
 3
 2
 1

3
5,6
 4
 3
 2
 1
4
 7
 6,7
 5
 4
 3
 2
 1
5
 8
 7,8
 6
 5
 4
 3
 2
6
 9
 8,9
 7
 6
 5
 4
 3
7
 10
 9,10
 8
 7
 6
 5
 4
8
 11
 10,11
 9
 8
 7
 6
 5
9
 12
 11,12
 10
 9
 8
 7
 6
10
 13
 12,13
 11
 10
 9
 8
 7

Note that packet 7 is sent at T=4 and the acknowledgement is received at T=10, for a RTT of 6.0 seconds.

               
SWS > bandwidth×delay: 
What happens is that the extra packets pile up at a router somewhere (specifically, at the router in front of the bottleneck link)
Delay rises (artificially); bandwidth is that of bottleneck link
                
example: SWS=6. Then the actual RTT rises to 6.0 sec.
Each second, there are two packets in the queue at R1.
avg_queue + bandwidth×RTT_noload = 2+4 = 6 = SWS
Now, however, RTT_actual is 6, and to the sender it appears that SWS = bandwidth × RTTactual.
                       

Note that in all three cases, in the steady state the sender never sends faster than the bottleneck bandwidth. This is because the bottleneck bandwidth determines the rate of packets arriving at B, which in tern determines the rate of ACKs arriving back at A, which in turn determines A's continued sending rate. This aspect of sliding windows is called self-clocking.


Graphs of SWS versus:

The critical SWS value is equal to bandwidth×RTT (where "bandwidth" is the bandwidth of the bottleneck link). Below this, we have:
For SWS larger than the critical value, we have

We can actually say a little more about the queue utilization. RTTnoload is the "propagation" time; any time in excess of that is spent waiting in a queue somewhere. Thus, we have queue_time = RTTactual - RTTnoload. The number of bytes in the queue is just bandwidth*queue_time; this represents the number of packets if we measure bandwidth in units of packets.

Normally we think of RWS=SWS. However, it is possible to have RWS < SWS. The most common example of this is RWS=1, which means the receiver throws away out-of-order packets.
   

2.4: error detection

parity
            1 parity bit catches all 1-bit errors
            No generalization to N!  That is, there is no N-bit combination that catches all N-bit errors.
       
IP/UDP/TCP checksums (the "Internet" checksum)
            ones-complement sum of 16-bit words A and B:
                form the twos-complement sum A+B
                if there is an overflow bit, add it back in as low-order bit
            Fact: ones-complement sum is never 0000 unless all bits are 0.
           
Rule of 9's: the internet checksum is in fact the remainder upon dividing by 216 - 1. This is perhaps the real reason for using ones-complement arithmetic in a twos-complement world.

weakness: transposing words leads to the same checksum.
            

CRC

[kind of shortchanged]

The CRC error code is based on long division of polynomials. We treat the message, in binary, as a giant polynomial m(x), using the bits of the message as successive coefficients (eg 10011011 = X7 + X4 + X3 + X + 1). We standardize a divisor polynomial p(x) of degree 32. We divide m(x) by p(x); our "checksum" is the remainder r(x), of max degree 31 (so it fits in a 32-bit word.

This is a reasonably secure hash against real-world network corruption, in that it is very hard for systematic errors to result in same hash code. (For sums, byte transposition or "matching bit" errors leaves sum unchanged)

CRC is not secure against intentional corruption; given msg1, there are straightforward mathematical means for tweaking last bytes of msg2 so that so crc(msg1) == crc(msg2)

quickie example of "mod2-polynomial" long division: addition = subtraction = XOR
                             
secure hashes (md5, etc)
             Nobody knows at all how to produce two messages with same hash
             

error-correcting codes

2-D parity (corrects 1-bit errors)
            fundamental role of error-correcting codes
            (= "forward error correction")