TCP/UDP/QUIC Flashcards
Name some specialitites of TCP
- Connection oriented
- in-sequence delivery of byte stream
- Reliable (bit error detection, TransportService DU loss detection & retransmit)
- Flow control (do not overwelm receiver)
- Congestion control (does not overwelm network
How does the sender know that packets are lost?
- Ack is not received in timeout
- Multiple duplicate ACKs: reordering or packet loss
3 duplicate ACKs -> fast retransmit
Name the formular for estimating a TCP rtt
(1-a) * estimated RTT + a* sampleRTT
What two parameters do we need to know for effective congestion control?
- RPprop: round trip propagation delay
- BtlBw: Bottleneck Bandwidth
What is the BDP?
Capacity how much data the link can “take”/hold
RTprop * BtlBw
How can you measure the fairness of multiple tcp flows?
Jain's fairness index \+returnval: 0-1 \+scale free \+ arbitraty num of flows \+k/n for perfectly fair flows (if rest is 0)
(sum flows)^2 / n * sum(flows^2)
Which congestion control algorithms exist for TCP?
TCP Tahoe (slow start, congest avoid) TCP Reno (fast retransmit, fast recovery) TCP Vegas (delay based, keep rtt const) TCP Cubic (loss based) TCP BBR (mix, keep 1 BDP inflight)
How do loss based cc algorithms work and what are advantages and disadvantages?algorithms?
no loss -> increase congest windows
loss -> decrease window
+ robust, reliable, efficient
- buffers kept full, high latency and perf drop on lossy links
How does TCP reno work?
AIMD: additive increase multiplicative decrease
CWND: congest wdw
sstresh: slow start thres
slow start: increase for every ack by 1 mss
congest avoid: effect. increase by 1mss every RTT
3 dupl acks: sstresh = CWND / 2
How does TCP Cubic work?
Loss based; estimate bandwitdth and try to use it. If nothing lost, explore for more
-> congestion window growth modeled after cubic function plateau. tries to recover fast to the bandwidth of last packet loss.
What are advantages and disadvantages of TCP Cubic?
+ cwnd growth independent of rtt
+ scalable to high BDP networks
+ more resilient against single packet loss
- buffers are filled faster
- buffers kept filled
How do delay based congestion control algorithms work and what are the advantages and disadvantages?
Measure delay to detect congestion. RTT increase: buffer filling somewhere.
+ less restrained by random packet loss
+ early congestion detection
+ high throughput w/ low latency
- one loss-based flow cancels all advantages
- poor performance against loss based flows
How does TCP Vegas work?
AIAD: Additivite increase additive decrease
continously measure rtts
delta = CWND * (RTT - RTTmin)/RTT
if delta > beta: decrease by 1mss
if delta < alpha: increase by 1 mss
When do you use loss based algorithms?
Background applications like update download - LEDBAT low extra delay background transport
What is the base idea of TCP BBR?
measure bottleneck bandwidth and RTT. -> same operation point as delay based algorithms.
max bandwidth is determined by weakest link.
Keep 1 BDP inflight: optimal usage
Send with BtlBw: do not create queues
Pacing vs ACK-clocking?
Pacing: control transmissions of packets of a windows across entire rtt
ACK-clocking: arrival rate of acks limits sending
bursts (ack compress, slow start, retransmissions) can create queues even if link is not used
Describe the startup phase of TCP BBR
Startup: double sending rate every RTT. Stop after 3 cons RTTs with < 25% delivery rate
-> Measure BtlBW
Describe the drain phase of TCP BBR
Drain: remove queue from startup
Describe the probe bandwidth phase of TCP BBR
Probe bandwidth: BtlBw * pacing gain
if no bw available: reduce sending rate afterwards
if bw available: BtlBw gets updated to increase sending rate
Describe the probe rtt phase of TCP BBR
Probe RTT: every 10s probe for RTprop -> Drain queues and measure. Mult BBR flows have to synchronize
What are advantages and disadvantages of BBR?
+robust against rand packet loss
+low delay, high BW usage
+close to optimal operation point
+ no starve against other cc
- alternating probeBW leads to 1.5 BDP
- Shallow buffers -> high amount of retransmissions
- flows w larger RTT receive larger BW than flows with lower RTT (opposite in Reno/Cubic)
What is UDP?
- Connection less transport protocol
- bit error correction
- no flow or congest control
- no reordering, loss detect, or recovery
What is SCTP?
Stream control transmission protocol - multi homing - multiple streams - advantages of tcp & udp But: poor adaptation, middleboxes often dropped packets (unknown protocol)
What is QUIC?
Quick UDP Internet Connections
substitute of TCP/TLS
- decrease handshake delay
- middlebox resistance
- ip mobility
- fast development cycles
What are connection IDs in quic?
Connection identifiers which are used instead of 5-tuple (proto, src ip, src port, dst ip, dst port)
-> allows chaning port and ip
What QUIC packet types do exist?
- Version negotiation packet
- initial packet
- retry packet
- handshake packet
How does QUIC perform loss detection and re-ordering?
Retransmissions have differen packet numbers -> stream offset allows in-order deliver
selective and negative ACKs
How does QUIC cope with handshakes?
0-RTT handshake: reuse old connections
1-RTT handshake: combine TCL & TLS ‘components’
How does a QUIC 1-RTT handshake work?
ClientHELO -> Server
Server -> Reject incl Certificate info
ClientHELO enc’ed -> Server (include cert)
ServerHELO enc’ed -> Client
What is head-in-line blocking? And how does QUIC fix it?
Lost tcp packet blocks all subsequent packets (including other streams) (in-order property of tcp).
Quick offers multiple streams. Retransmission blocks on stream-level not connection-level.
Why can quick be developed faster?
Not implemented in kernel: UDP Is but does not change, QUIC can be updated
Name the 5 goals quick wants to fullfil.
1 Minimize connection establishment and transport latency
2 No head of line blocking
3 Requiring only changes to path endpoints to enable deployment (not middleboxes)
4 Multipath & fwd error correction
5 always secure, tls1.3
