1 / 10

Changes in CCID 2 and CCID 3

Changes in CCID 2 and CCID 3. Sally Floyd August 2004 IETF. CCID 2:. Changes from draft-ietf-dccp-ccid2-05.txt: Response to Idle and Application-limited Periods Detecting Lost and Marked Acknowledgements. Section 5.1: Response to Idle and Application-limited Periods. What does TCP do?

medea
Download Presentation

Changes in CCID 2 and CCID 3

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. Changes in CCID 2 and CCID 3 Sally Floyd August 2004 IETF

  2. CCID2: Changes from draft-ietf-dccp-ccid2-05.txt: • Response to Idle and Application-limited Periods • Detecting Lost and Marked Acknowledgements

  3. Section 5.1: Response to Idle and Application-limited Periods What does TCP do? • RFC 2581 says that TCP SHOULD slow-start after an idle period. • RFC 2861, Experimental, has a slightly more moderate mechanism for TCP.

  4. Section 6.1.1: Detecting Lost and Marked Acknowledgements • When a packet is lost from DCCP B to DCCP A, DCCP A doesn't know if this was a data packet or an ACK packet. • For the purposes of Ack Ratio calculation, DCCP A assumes that every loss from DCCP B to DCCP A was an ACK loss. - (The NDP Count option can give more information.)

  5. Section 6.1.1, continued: Appendix B: Cost of Loss Inference Mistakes to Ack Ratio • The cost occurs when DCCP B is sending roughly the same amount of data and non-data packets, without NDP Count options, with all acknowledgement information in DCCP-Ack packets. • The cost is moderate.

  6. CCID 3: Changes from draft-ietf-dccp-ccid3-05.txt: • Response to Idle and Application-limited Periods • Response to Data Dropped and Slow Receiver • Other Possible Changes to TFRC • Added a paragraph on the sending rate when no feedback is received from the receiver. (Specified in RFC 3448.) • Expanded on the discussion of the packet size s used in the TCP throughput equation. (One could set the packet size s to MSS).

  7. Section 5.1: Response to Idle and Application-limited Periods • After an idle period, the allowed sending rate is not reduced to less than the initial sending rate. • After that, the sending rate is at most doubled from one RTT to the next.

  8. Section 5.2: Response to Data Dropped and Slow Receiver • Adjusting the receive rate after Data Dropped or Slow Receiver events, to limit the sending rate in the next RTT. This is "SHOULD".

  9. Section 10.2: Other Possible Changes to TFRC Issues listed for future research and engineering: • Sending fewer acknowledgements when the sending rate is low (less than one packet per RTT)? • More than doubling the sending rate, from one RTT to the next? • A higher sending rate after an idle period? • Follows an old section on Possible Changes to the Initial Window.

  10. Possible new efforts: • Standardizing QuickStart (for a faster start-up, with feedback from routers). • A new CCID for VoIP based on RFC 3714, IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet. • At some point, TFRC-PS, a variant of TFRC for flows that adapt their packet size.

More Related