retransmission timeout requirements
play

Retransmission Timeout Requirements Mark Allman International - PowerPoint PPT Presentation

Retransmission Timeout Requirements Mark Allman International Computer Science Institute IETF-98, Chicago, IL March 2017 History draft-ietf-tcpm-rto-consider-05.txt Started eons ago as a way to relax TCP RTO spec (RFC 6298) we have


  1. Retransmission Timeout Requirements Mark Allman International Computer Science Institute IETF-98, Chicago, IL March 2017

  2. History • draft-ietf-tcpm-rto-consider-05.txt • Started eons ago as a way to relax TCP RTO spec (RFC 6298) • we have learned what is important … 
 … and what is not • so, explicitly give implementers latitude • reality check: they take the latitude anyway! Allman 2

  3. Status wrt TCP • It seems that document has—for a good long while—had solid consensus • converged on the technical meat • But … Allman 3

  4. History, part 2 • The requirements in the document actually seem quite general • i.e., what would not apply to some other protocol as a general statement? • Hmm…. • so, hacked on the draft to make it broad and general • i.e., no longer TCP specific 
 … although still applicable to TCP Allman 4

  5. History, part 2 • Document was foundation of a small subset of the UDP Guidelines document (RFC 8085) • RFC 8085 & rto-consider agree in normative statements • …except RFC 8085 does not call for exponential backoff • … hmm … <grumble> 
 (yes, I reviewed RFC 8085 extensively … alas) Allman 5

  6. Quick Overview • Initial RTO MUST be at least 1sec • RTO SHOULD be based on recent measurements of feedback time • RTO SHOULD be based on regular measurements of the feedback time • feedback time MAY be measured with non-data segments (e.g., heartbeats) • ambiguous feedback time sample MUST NOT be used Allman 6

  7. Quick Overview • Exponential backoff MUST be used for repeated retransmissions • Exponential backoff SHOULD be removed after successful repair of loss • a maximum RTO MAY be used, but MUST NOT be less than 60sec • Retransmissions triggered by the RTO MUST be taken as indications of congestion and trigger a some standard response Allman 7

  8. History, part 2 • Recent changes to relax a couple of MUSTs to SHOULDs • to explicitly give a little wiggle room to implementers • to sync w/ the UDP guidelines Allman 8

  9. The Plan We Agree On • Get some feedback from non-TCP folks • SCTP feedback from Tuexen already (thanks!) • WGLC … • … in TCPM because that is where this all started • … in TSVWG because the scope has widened • Ultimately the more reviewing the better Allman 9

  10. The Unknown Part of The Plan • For TCP? UDP? SCTP? DCCP? Etc. • General game plan: • write what we know to be our best advice • trust implementers to apply the advice as faithfully as possible within their own constraints • (suggested by Mirja) Allman 10

  11. Questions? Comments? Mark Allman mallman@icir.org http://www.icir.org/mallman/ @mallman_icsi

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend