1 / 11

RFC1323bis – TCP Extensions for High Performance

RFC1323bis – TCP Extensions for High Performance. Richard Scheffenegger (Editor) David Borman Bob Braden Van Jacobson . RFC1323bis. 20 years since adoption of RFC1323 New revision started in 5 years ago WG Item quite some time (4 years) Shepherd document to finish line

hashim-torres
Download Presentation

RFC1323bis – TCP Extensions for High Performance

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. RFC1323bis –TCP Extensions for High Performance Richard Scheffenegger (Editor) David Borman Bob Braden Van Jacobson 84th IETF, Vancouver, Canada

  2. RFC1323bis • 20 years since adoption of RFC1323 • New revision started in 5 years ago • WG Item quite some time (4 years) • Shepherd document to finish line • Two updates -02 and -03 84th IETF, Vancouver, Canada

  3. Changes since draft-ietf-tcpm-1323bis-01 • Changed format from noff to xml2rfc • addressed some nits around indentation • new citation and TOC style • removed references to historic RFC1072 • Caret ^ instead of C-style ** for exponential notation 84th IETF, Vancouver, Canada

  4. Changes since draft-ietf-tcpm-1323bis-01 • Content: • Window Scale (WS): • sec 2.4 window retraction – M. Mathis • Timestamp (TS): • sec 3.2 removed text to allow potential in-session negotiation of TS – M. Mathis • sec. 3.3 explicitly excluding ACKs with selective acknowledgements (SACK) for round trip-time measurement (RTTM) processing – R. Scheffenegger • Lots of typos and inconsistencies Thanks to A. Hoenes, A. Zimmermann 84th IETF, Vancouver, Canada

  5. Open in draft-ietf-tcpm-1323bis-03 • RFC2119 BCP wording • Text around Nyquist criteria Delay in a packet network is not a time-continuous function (A. Hoenes) • Protection against wrapped sequence numbers (PAWS) check criteria discarding of reordered, pure ACKs no effect on reverse data (A. Zimmermann) • Processing Order e.g. pure ACK dropped by PAWS but may be interesting for RTTM, SACK,.. increases attack surface • Middlebox issues (Window Scale) 84th IETF, Vancouver, Canada

  6. Poll around draft-ietf-tcpm-1323bis-03 • Who has read either -02 or -03 draft? • Objections to format, style? • Objections to modified content? • Feedback around open points? • Ready for WGLC (after RFC2119 update)? 84th IETF, Vancouver, Canada

  7. 84th IETF, Vancouver, Canada

  8. Backup NetApp Confidential - Internal Use Only

  9. Window Scale Retraction • Expanded text to dedicated section 2.4 • Explicitly quoted section 4.2.2.16 of RFC1122 to describe the expected behavior. 84th IETF, Vancouver, Canada

  10. Timestamp negotiation • Allow late negotiation: Old: A TCP may send the Timestamps option (TSopt) in an initial <SYN> segment (i.e., a segment containing a SYN bit and no ACK bit), and may send a TSopt in other segments only if it received a TSopt in the initial <SYN> or <SYN,ACK> segment for the connection. New: A TCP may send the Timestamps option (TSopt) in an initial <SYN> segment (i.e., a segment containing a SYN bit and no ACK bit). 84th IETF, Vancouver, Canada

  11. Timestamp RTTM processing • Only reflect timestamp from last in-sequence data packet. • Only process timestamp when new data is acknowledged. • However, ACK loss may lead to increased RTT (first ACK in a series of duplicates lost) • Presence of SACK option indicates that reordering/loss was present at the receiver, sender SHOULD ignore that RTT update. 84th IETF, Vancouver, Canada

More Related