CS/ECE 438: Communica on Networks

Reliable Transport: Goals and Design Considera ons

Saksham Agarwal
1
ti
ti
Recap: breaking down end-to-end network func onality into (simpler) tasks
• Transmit data (bits) over communica on channel (wire, air, …): Physical (layer 1)

• Forwarding data (packets) between neighboring network elements: Link (layer 2)

• Rou ng data across (global) network elements: Network (layer 3)

• Deliver data between host processes: Transport (layer 4)

• Do something with the data: Applica on (layer 5)

2
ti
ti
ti
ti
Recap: Five layers (Top - Down)
• Applica on (L5): Providing network support for apps

• Transport (L4): (Reliable) end-to-end delivery

• Network (L3): Rou ng across networks

• Link (L2): Forwarding across a network link

• Physical (L1): Bits on wire

3
ti
ti
 Recap: Layering

• A kind of modularity
Applica Built on top of reliable delivery
• Func onality separated into layers

• Layer n interfaces with only layer n-1 and n+1 Socket

• Hides complexity of surrounding layers
Data Transport (L4) Built on top of (global) rou ng
• Interface between successive layers?
L4
• Sockets and packet headers! Segment
• Each layer encapsulates its header L4 Data Network (L3) Built on top of (local) forwarding

L3
Datagram
L3 L4 Data Data Link (L2) Built on top of data communica on

L2
Frame
L2 L3 L4 Data Physical (L1)

4
ti
ti
ti
ti
Goal of today’s lecture
• Understanding reliable transport conceptually
• What are the fundamental aspects of reliable transport

• Back to architectural principles for one lecture

• The goal is not to understand a par cular protocol (eg., TCP)

• TCP involves a lot of detailed mechanisms, covered later

• Ground rules for discussion

• No men on of TCP
• No men on of detailed prac cal issues
• Focus only on “ideal” world of packets and links

5
ti
ti
ti
ti
You must think for yourself
• Today’s lecture requires you to engage
• How would I design a reliable service

• I will ask a lot of ques ons today!

• I want you to think about them

6
ti
Best e ort service (L3)
• Packets can be lost

• Packets can be corrupted

• Packets can be reordered

• Packets can de delayed

• Packets can be duplicated

• …

How can you possibly make anything work with such a service model?!

7
ff
Reliable transport is necessary
• Some app seman cs involve reliable transport
• Eg., le transfer

• L3 and below provide only unreliable packet delivery

• Today’s ques on:

• How can we build a reliable transport service on top of arbitrary unreliable packet delivery

• A central challenge in bridging the gap between

• The abstrac ons applica on designers want
• The abstrac ons networks can easily support

8
fi
ti
ti
ti
ti
ti
Challenge for today
• What mechanisms can we put in the transport layer (L4) to provide reliability?

• Reliability is focused on a single “ ow”

• Flow: stream of packets between two processes
• Usually de ned using the 5-tuple
• (Source IP, Des na on IP, Source Port, Des na on Port, protocol)

9
fi
ti
ti
fl
ti
ti
 Four goals for reliable transfer
• Correctness
• To be de ned

• “Fairness”
• Every ow must get a fair share of network resources

• Flow performance
• Latency, ji er, etc

• U liza on
• Would like to maximize bandwidth u liza on
• If network has bandwidth available, ows should be able to use it!

10
ti
fl
ti
fi
tt
fl
ti
ti
Correctness condi on
• We want some kind of “if and only if” characteriza on of “correct” reliable transport design
• i.e. the reliable transport design is correct, if and only if, condi ons X,Y,Z are true…

• Remember: the condi on for the design to be correct, not the best performant

• One obvious requirement

• Transport never claims to have delivered data that wasn’t delivered…

• But we need more than that. What?

11
ti
ti
ti
ti
 Correctness condi on
• How about: “packet is always delivered to the receiver”?
• i.e., transport is reliable if and only if packets are always delivered to the receiver…
• Isn’t that simple?

• Wrong!
• What if network is par oned?
• Par on means network is broken into two or more disconnected components
• We can’t claim a transport design is incorrect if it doesn’t work in a par oned network!
• A er all, there is no way to reach the des na on.

12
ft
ti
ti
ti
ti
ti
ti
ti
ti
ti
Correctness condi on
• How about: “packet is delivered to the receiver if and only if it is possible to deliver the packet”?

• Wrong!
• If the network only available at one instant of me, only an oracle would know when to send!
• We can’t claim a transport design is incorrect if it doesn’t know the unknowable

• So we need to focus on what the transport design is trying to do, not what it actually accomplishes

13
ti
ti
Correctness condi on
• How about: “packet is resent to the receiver if and only if the previous transmission was lost or corrupted”?

• This is be er because it refers to

• What the design does (which it can control)
• Not whether it always succeeds (which it can’t)

• Wrong!
• Consider following two cases
• Packet delivered to the receiver; all packets from the receiver are dropped
• Packet dropped en route to receiver; all packets from the receiver are dropped
• They are indis nguishable to the sender
• In both cases, packet was sent, but no feedback at all
• Does it resend or not?

14
tt
ti
ti
 Correctness condi on
• How about: “packet is resent to the receiver if the previous transmission was lost or corrupted”?

• “And, packet may be resent at other mes”

• Note:
• This invariant gives us a simple criterion for deciding if an implementa on is correct
• E ciency and simplicity are separate criteria

• Almost right!
• What’s wrong with it?
• An implementa on that never sent a packet at all is reliable according to this de ni on!

15
ffi
ti
ti
ti
ti
fi
ti
Complete correctness condi on
• A transport mechanism is reliable if and only if:
1. It resends all dropped or corrupted packets

2. It a emps to make progress

• Making progress means:

• If there’s data to send, transport eventually a empts to send data
• Very important: “eventually a empts”
• It should not be blocked forever
• And, it may not succeed, but it must a empt

• Example: if there are 10 packets to send, transport can’t just send rst 5 and then stop forever

16
tt
tt
tt
ti
tt
fi
 Complete correctness condi on
• A transport mechanism is reliable if and only if:
1. It resends all dropped or corrupted packets

2. It a emps to make progress

• Su cient (if): transport algorithm will keep trying to deliver packets that have not yet reached the des na on

• Necessary (only if): if it ever lets a packet go undelivered without trying again, or never tries to send a packet when
all others have been delivered, it isn’t reliable

17
ffi
tt
ti
ti
ti
Important note
• A transport mechanism can “give up”, but must announce this to the applica on

• If the transport mechanisms has tried for some period to deliver the data, and has not succeeded
• It might decide that it is be er to give up
• And applica ons can reini ate the data transfer
• That is allowed…

• But can never falsely claim to have delivered the packet

18
ti
ti
tt
ti
We have the correctness condi on
• How do we achieve it?

• Focus on single packet solu ons

• Simpler case to begin with
• Worry about larger les later

19
fi
ti
ti
Solu on v1
• Send every packet as o en and as fast as possible

• Is it correct?
• No
• Why?
• No way to check whether the packet was dropped or corrupted
• Cannot ensure both if condi ons true at the same me!

20
ti
ft
ti
ti
What’s missing?
• Feedback from receiver!

• If receiver does not respond, no way for sender to tell when to stop resending
• Cannot achieve correctness without feedback

21
Forms of feedback
• ACK: Yes, I got a packet

• NACK: No, I did not get the packet

• When is NACK a natural idea?

• Packet corrup on (I got packet #5, but it was corrupted)

• Ignore NACKs for the rest of the lecture…

22
ti
 Solu on v2
• Resend packet un l you get an ACK
• And receiver sends per packet ACKs un l data nally stops

• Correct?
• Yes
• All dropped/corrupted packets will be retransmi ed
• The transport will a empt to make progress

• Fair?
• Over long-term, yes
• All sources will get an equal chance to use network resources
• Flow performance
• Good, but not necessarily op mal
• Some packets may be retransmi ed unnecessarily
• E ciency
• Sub-op mal; packets retransmi ed unnecessarily
23
ffi
ti
ti
ti
tt
ti
tt
tt
ti
fi
tt
 Solu on v3
• Send packet
• But now, set a mer

• When receiver gets packet, sends ACK

• If sender receives ACK, done

• If no ACK when mer expires (i.e. a meout), resend

• S ll correct and fair

• Performance would argue for small meout

• U liza on would argue for large meout

24
ti
ti
ti
ti
ti
ti
ti
ti
ti
Have “solved” the single packet case
• Send packet
• But now, set a mer

• If no ACK when mer goes o , resend packet

• And reset mer

• Tradeo between performance and u liza on in selec on of meout:

• Too small: unnecessary retransmissions (underu liza on)
• Too large: wai ng unnecessarily (poor performance)

25
ff
ti
ti
ti
ti
ff
ti
ti
ti
ti
ti
ti
Mul ple packets
• Service model: reliable stream of packets
• Hand up con guous block of packets to applica on

• Why not use single packet solu on?

• Send the next packet once the rst one has been delivered
• Problem: only one packet in- ight at a me
• Low e ec ve throughput: Packet size / RTT
• Use window-based approach
• Allow for a window of W packets in- ight at any me (unACK’d)
• Slide the window as packets are ACK’d
• Sliding window implies W packets are con nuous

26
ti
ff
ti
ti
fl
ti
fi
fl
ti
ti
ti
ti
Window-based algorithms
• A very simple concept
• Send W packets
• When one gets ACK’d send the next packet in line
• It is really that simple (un l we go to T**)

• Will consier several varia ons

• But rst…

27
fi
ti
ti
How big should the window be?
• Windows serve three purposes
1. Taking advantage of bandwidth of the links
2. Limi ng bandwidth used by a ow (conges on control)
3. Limi ng the amount of bu ering used at the receiver ( ow control)
• Why do receivers need to bu er packets?
• Answer: packet re-ordering (discussed later)
• If we ignore all but rst goal, then we want to keep the sender always sending (in the ideal case)
• RTT: from sending rst packet un l received rst ACK

• Condi on:
• RTT x B ~ W x packet size

28
ti
ti
ti
fi
fi
ff
ff
fl
ti
ti
fi
fl
What does this mean?
• B is the minimum link bandwidth across the path
• Obviously shouldn’t send faster than that
• Don’t want to send slower than that (for rst goal)

• We want to set W such that

• If I am sending at rate B, then
• the ACK of the rst packet arrives
• Exactly when I just nished sending the last of my W packets

• Let me send as fast as the path can deliver…

29
fi
fi
fi
RTT x B ~ W x Packet Size
• Bandwidth Delay Product
• BDP = bandwidth x propaga on delay

bandwidth delay x bandwidth

Propagation delay

• B x RTT is merely 2 x BDP

• Window sizing rule:

• Total bits in ight roughly the amount of data that ts into the forward and reverse “pipes”
• Here, pipe is the complete path (not individual links)

• This is not a detail, but a fundamental concept!

30
fl
ti
fi
Where are we?
• Figured out correctness condi on (from rst principles)
• Always resent lost/corrupted packets
• Aways try to make progress (but can give up en rely and inform the apps)

• Figured out a single packet case

• Send packet, set mer, resend if no ACK when mer expires

• Some progress toward mul -packet case

• Allow many packets (W) in ight at once
• And know the ideal window size is
• RTT x B / packet size
• What’s le to design?

31
ft
ti
fl
ti
ti
fi
ti
ti
Three design considera ons
• Nature of feedback
• What should ACKs tell us when we have many packets in ight

• Detec on of loss
• Is relying on mers the best we can do?

• Response to loss
• Should senders only resend the packets in response to loss?

32
ti
ti
ti
fl