QCon London 2015 Protocols of Interaction
•
6 likes•1,647 views
Slide deck from QCon London 2015 session on Protocols of Interaction.
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to QCon London 2015 Protocols of Interaction
Similar to QCon London 2015 Protocols of Interaction (20)
Recently uploaded
Recently uploaded (20)
QCon London 2015 Protocols of Interaction
- 1. Protocols of Interaction Best Current Practices Todd L. Montgomery @toddlmontgomery
- 2. What is a Protocol? Why should I care!?
- 3. @toddlmontgomery pro·to·col noun ˈprō-tə-ˌkȯl, -ˌkōl, -ˌkäl, -kəl ... 3 b : a set of conventions governing the treatment and especially the formatting of data in an electronic communications system <network protocols> ... 3 a : a code prescribing strict adherence to correct etiquette and precedence (as in diplomatic exchange and in the military services) <a breach of protocol>
- 4. Protocols of Interaction Matter
- 5. In an emerging era of micro-services, protocols of interaction matter Protocols are a rich source of solutions to micro-service problems
- 7. Networks, and especially the Internet, are Hostile Environments
- 9. Data can be lost, duplicated, and re-ordered!!
- 10. TCP connections can… be closed unexpectedly end in an unknown state be intercepted by idiots, er Proxies
- 11. Duplicated Re-Ordered Lost Which means Data over TCP* might be… * - When connections are re-established
- 12. Case Study 1 Loose Ordering = The New Normal (De)multiplexing
- 13. @toddlmontgomery Sync Requests & Responses Request Request Request Response Response Response Throughput limited by Round-Trip Time (RTT)!
- 14. @toddlmontgomery Async Requests & Responses Request Request Request Response Response Response Throughput less limited by Round-Trip Time!
- 15. @toddlmontgomery Async Requests & Responses Correlation! Request 0 Request 1 Request 2 Response 0 Response 1 Response 2
- 16. Aside…
- 17. Ordering is an Illusion!!
- 18. Compiler can re-order Runtime can re-order CPU can re-order
- 19. Ordering has to be imposed!
- 20. @toddlmontgomery Async Requests & Responses Correlation! Request 0 Request 1 Request 2 Response 0 Response 1 Response 2
- 21. @toddlmontgomery Correlation! Request 0 Request 1 Request 2 Response 0 Response 1 Response 2 Ordering
- 22. @toddlmontgomery Correlation! Request 0 Request 1 Request 2 Response 0 Response 1 Response 2 (Valid) Re-Ordering
- 23. @toddlmontgomery Handling the Unexpected Request 0 Response 1 Invalid, Drop We only know of 0. 1 is unknown!
- 24. SCTP HTTP/2 (SPDY) … most OSI Layer 4 protocols
- 25. Case Study 2 Can you hear me now? Timeouts & Retries
- 30. @toddlmontgomery Interval = N x “typical” RTT Account for processing delay X TimeoutInterval “Average”
- 31. @toddlmontgomery Measure! But very “noisy”? RTTMeasurement Variances in processing, transmission, etc.
- 32. TCP Retransmit Timeout (RTO) Err = M - A A <- A + gErr D <- D + h(|Err| - D) RTO = A + 4D M = measurement, A = smoothed average, D = smoothed mean deviation, g and h = gain constants (0 to 1)
- 33. TCP Retransmit Timeout (RTO) Err = M - A A <- A + gErr D <- D + h(|Err| - D) RTO = A + 4D Do you measure on a Retransmit? NO!
- 34. @toddlmontgomery Does processing twice hurt? X Original ACK Retrans Process Once Process Twice TimeoutInterval
- 35. @toddlmontgomery Are Original & Retransmit treated the same? X Original ACK Retrans Process Once Process Twice TimeoutInterval
- 37. Case Study 3 What I Need! When I Need It! “Lifetime” Management
- 39. Caching Algorithms LRU, MRU, PLRU, RR, SLRU, LFU, … “Liveness” is essential
- 41. @toddlmontgomery Request ACK Service A is Alive! Service B is Alive! Service A Service B Consequence of Processing
- 42. @toddlmontgomery Keepalive Keepalive Service A is Alive! Service B is Alive! Service A Service B Absence of Processing
- 43. RIP Route Deletion Step 0 - route info broadcast @30 seconds Step 1 (3 min) - Set Distance to Infinity (16) Step 2 (+1 min) - Delete Route Aside… RIP… aptly named
- 44. Aeron Driver Keepalive Time of Last Activity = Shared Variable Doesn’t need to be a message…
- 45. @toddlmontgomery Bye Bye Service A is gone! Service B is gone! Service A Service B Optimization, but insufficient with arbitrary failures
- 46. Liveness often exists across transient connectivity
- 47. So… Don’t conflate transport state with liveness! Like TCP connection state
- 49. Case Study 4 Elasti-What? Self-Similar Behavior
- 50. Request X Request X Request X Request X, X, X Multiple same/similar requests at the same time Response X, X, X
- 52. 1, 2, 3 1, 2, 3 1, 2, 3 1, 2, 3 Non-correlated loss X X X
- 53. NAK 1, 2, 3 NAK 2 NAK 1 NAK 3 Request individual lost data Retransmit 1, 2, 3
- 54. 1, 2, 3 1, 2, 3 1, 2, 3 1, 2, 3 Temporally/Spatially Correlated Loss X X X
- 55. NAK 2 NAK 2 NAK 2 NAK 2, 2, 2 Multiple requests for same data Retransmit 2, 2, 2
- 56. Request 2 Request 2 Request 2 Request 2, 2, 2 It’s a generic problem!
- 57. Request 2 Request 2 Request 2 Request 2, 2, 2 Overloading Responder & Network
- 59. Request 2 Don’t Immediately Request, Listen first Timeout! Request 2 Request 2 Suppress Request
- 60. Request 2 How long to wait & listen for? Timeout! Request 2 Request 2 Suppress Request
- 61. Statistics to the Rescue!
- 62. SRM Backoff RandomBackoff = [C1, C1+C2] * 1-way delay Random is more than good enough
- 63. Optimal Multicast Feedback double RandomBackoff(double T_maxBackoff, double groupSize) { double lambda = log(groupSize) + 1; double x = UniformRand(lambda/T_maxBackoff) + lambda / (T_maxBackoff*(exp(lambda)-1)); return ((T_maxBackoff/lambda) * log(x*(exp(lambda)-1)*(T_maxBackoff/lambda))); } Truncated Exponential Distribution
- 64. Request 2 Request 2 Request 2, 2 Must also shed duplicates on the responder Response 2, 2 Shed second “Request 2” if too soon X X
- 66. Case Study 5 Hey, Slow Down! Flow (& Congestion) Control
- 68. @toddlmontgomery Data Data Data ACK ACK ACK Throughput = Data Length / RTT RTT Stop-And-Wait Flow Control
- 69. Delay Bandwidth BDP = (Byte / sec) * sec = Bytes BDP (Buffer)
- 70. @toddlmontgomery Data ACK RTT Throughput = N * Data Length / RTT … N Data “Blobs”
- 71. So… How big is N? This is surprisingly hard to answer
- 72. It depends…
- 73. Big… but Don’t overflow receiver Don’t overflow “network”
- 74. TCP Flow Control Receiver advertises N
- 75. TCP Congestion Control Sender probes for network N
- 76. TCP Sender min(Receiver N, Network N) Only go as fast as Network & Receiver
- 78. One more thing…
- 79. Queue Management Perhaps the single most useful thing!
- 80. Effective management of queues can not be overlooked
- 81. Unbounded Queues are bad, m’kay
- 82. Bounding implies Back pressure and/or Dropping
- 83. CoDel locally minimize delay in queue combat bufferbloat http://en.wikipedia.org/wiki/CoDel
- 84. Just a taste…
- 85. Takeaways!
- 86. Protocols are a rich source of solutions to complicated problems Protocols of interaction matter & can be tremendously impactful for better or worse…
- 87. @toddlmontgomery Questions? • IETF http://www.ietf.org/ • Aeron https://github.com/real-logic/Aeron • SlideShare http://www.slideshare.com/toddleemontgomery • Twitter @toddlmontgomery Thank You!