1 / 6

RDDP TCP Mapping: Rough Consensus Summary

RDDP TCP Mapping: Rough Consensus Summary. David L. Black RDDP WG Chair IETF Vienna – July 2003. Status of TCP mapping issues. “What a long strange trip it’s been” The Grateful Dead Most major TCP mapping issues are now closed Sender Alignment Markers CRC Summary of resulting positions

nerina
Download Presentation

RDDP TCP Mapping: Rough Consensus Summary

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. RDDP TCP Mapping:Rough Consensus Summary David L. Black RDDP WG Chair IETF Vienna – July 2003

  2. Status of TCP mapping issues • “What a long strange trip it’s been” • The Grateful Dead • Most major TCP mapping issues are now closed • Sender Alignment • Markers • CRC • Summary of resulting positions • Clarification questions are ok, BUT ... • ... please do not re-open these issues

  3. Sender Alignment • Alignment of upper layer PDUs (ULPDUs) to transmitted TCP segments • Resolution (San Francisco – March 2003) • Alignment is an optimization (MAY) • No MUST or SHOULD alignment requirement • Ok to Describe circumstances where sender use of alignment improves performance • Ok to use lower-case “should” to recommend alignment in those circumstances

  4. Markers • Markers locate ULPDU boundaries in out-of-order reception cases (e.g., drops) • Resolution (mailing list – May 8, 2003) • Marker usage is OPTIONAL • Marker usage is determined by receiver • Senders MUST support markers AND no-markers • Receivers MUST support markers OR no-markers • Receiver in each direction determines what is used • The inter-marker interval is 512 bytes

  5. CRC • Use of CRC to protect header and data • Resolution (mailing list – July 9, 2003) • (A) MUST implement CRC support • (B) CRC usage is all-or-nothing on header + data • Note: One vs. two CRC issue is still open • (C) CRC usage is bidirectional: both or neither • (D) CRC omission requires consent of both ends of connection – i.e., either end can force CRC usage • (E) CRC usage is OPTIONAL [but, c.f. (D)] • (E’) CRC usage is admin. config, not visible to protocols • ULP design discussion in applicability statement draft

  6. Last? CRC issue • (B’) One vs. Two (header and data) CRCs? • Case for Two: • Fast placement: check header, then can immediately place data • Don’t have to wait for data in order to validate header • Case for One: • Single CRC not an obstacle to flow-through design – data size limited by packet size • Simpler to generate and check one CRC • Header/data boundary = layering abuse

More Related