Networks and Distributed Systems ND group Modularizing TCP with timers Michael Welzl Net Group University of Rome Tor Vergata 25 09 2017 Goal Dissect TCP into generalpurpose transport protocol modules such that some can become hardware primitives ID: 784064
Download The PPT/PDF document "Department of Informatics" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Department of InformaticsNetworks and Distributed Systems (ND) group
Modularizing TCP with timers
Michael Welzl
Net Group, University of Rome Tor Vergata
25. 09. 2017
Slide2GoalDissect TCP into general-purpose transport protocol modules such that some can become hardware primitives
So that we can SDN-enable TCP and other transportsEnd result: simpler code, hardware-supported, platform-independentWhich modules are there?
Slide3Transport modules
Module
TCP Status
Connection management
?
Buffer management / communication with app (sender, receiver)
?
Constructing headers (data, ACK)
Hardware support,
I think?
Sending packets (data, ACK)
TSO, GSO,
pacing
Receiving and parsing packets (data, ACK)
Hardware support, I think?
Checksum calculation
Hardware support exists
Flow control
= receiver buffer management?
Congestion control
"Pluggable" in Linux and FreeBSD
Loss recovery
A mess
! (also messes up CC "module")
Slide4TCP today
CA
FR
SS
Where we
want to be
. When we don't lose packets, even with an ECN cwnd reduction, we stay there!
Where we
end up after loss
Start
the connection
;
we're clueless!
Designed
as a replacement for starting with, e.g., cwnd=370
Not "pluggable" today!
Noooooooo !!!!! NOOOOOO !!!!!! DON'T LET IT HAPPEN !!!
http://theoatmeal.com
Slide5The "ACK clocking" rule
Packet conservation principle important, bla blaACK clock, must preserve, bla blaIs a bursty ACK-clocked TCP better, or a paced non-ACK clocked TCP?CA: cwnd+=1 breaks ACK clocking
SS breaks ACK clocking
IW10 breaks ACK clocking
TLP/RACK = FR slightly deviating from ACK clocking!
Strict ACK-clocking only applied in FR
What good has it done us?
Slide6ACK-clocking in FREstimate "pipe": number of packets in flight
Try to keep that constant"in flight" really means: "in flight" + "in queue"Try hard to keep the queue filled???
Fantastic!
For instance, can't handle drops of retransmits
This has been called a "feature"
RACK can handle it... but (currently?) won't reduce cwnd again...
Slide7Standing queues do exist: Reno...
All tests with:
3-host topology, 5
Mbit/s
bottleneck in CORE emulator; 1500-byte packets
Default queue:
DropTail
(FIFO
), 100 packetsQlen exceeds BDP in all our tests (base RTT 100ms: BDP = 41 packets).
Slide8... and Cubic...
Slide9Remember PRR?It can make things worse, it seems!
RFC 6675ack# X 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
cwnd: 20 20 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11 11
pipe: 19 19 18 18 17 16 15 14 13 12 11 10 10 10 10 10 10 10 10
sent: N N R N N N N N N N N
Rate-Halving (Linux)
ack# X 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
cwnd: 20 20 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11
pipe: 19 19 18 18 17 17 16 16 15 15 14 14 13 13 12 12 11 11 10
sent: N N R N N N N N N N N
Queue drains a little
Slide10This can cause a "double drop"...From:"Virtualized Congestion Control"
Tech.rep. longer version of SIGCOMM'16 paper http://webee.technion.ac.il/~isaac/p/sigcomm16_vcc_extended.pdf
Slide11A test from one of my Ph.D. students
Is this PRR? We believe so...
But everyone thinks that PRR is only a good thing?
Slide12Solving the loss recovery problemBasic function that all protocols need:
Remember which packets were sent / ACKed, and when, for re-sending and RTT calculation ("scoreboard")I claim: scoreboard operations could be much simpler, and that might even make them better
Going in the direction of RACK, but "all the way":
base everything on a timer
Slide13What I envision
CA
SS
Only
at
the beginning!
Simple
rules for
increase/decrease events
(magnitude determined
by CC like before)
Increase:
upon ACK
Decrease:
upon ECN or loss
Loss determined via (aggressive, not RTO!)
per-packet timeout; reduce every time!
Undo if we got it wrong (ACKs that shouldn't have arrived – spurious loss det.), adjust timersAvoid over-reacting: look at ACK rate + RTTNo need for RTO with SS
because we back-off exponentially(instead of: cwnd*=factor, then cwnd=1)
Already done today with ECN !
Slide14End resultMuch simplermore robust? As good as PRR but can better handle lost retransmits?
Any other direct benefits?More modular
Slide15Thoughts?