1 / 6

Requirements for ROHC TCP

Requirements for ROHC TCP. Lars-Erik Jonsson Ericsson Research, Luleå Sweden lars-erik.jonsson@ericsson.com ROHC @ IETF 50, Minneapolis 2001-03-23. Outline. The 00 draft Open issues and comments received How to proceed. draft-ietf-rohc-tcp-requirements-00.txt.

march
Download Presentation

Requirements for ROHC TCP

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. Requirements for ROHC TCP Lars-Erik Jonsson Ericsson Research, Luleå Sweden lars-erik.jonsson@ericsson.com ROHC @ IETF 50, Minneapolis 2001-03-23

  2. Outline • The 00 draft • Open issues and comments received • How to proceed

  3. draft-ietf-rohc-tcp-requirements-00.txt • 2.2-5. TCP: Compression also in the cases when the SYN or FIN bits are set • 2.2-6. TCP Options that should be compressed • Window scale • Selective acknowledgements (SACK) • Timestamp • 2.3-2. For TCP, it is not a primary goal to have robustness mechanisms • 2.3-3. The scheme should provide mechanisms for efficient compression of short-lived TCP transfers • 2.4-4. The TCP scheme must be part of the ROHC framework

  4. Open issues and comments received, 1(2) • The requirements assume reliable link layers for TCP traffic • Is this ok? Any input from PILC on this one?? • Otherwise, should we have multiple profiles, adjustable robustness within a profile or always provide a certain amount of robustness at the expense of efficiency? • If non-reliable links is an issue, should that be clarified in each section that is reflected or should the 2.3 requirements be defined in two sections, one for reliable and one for unreliable link layers? • Support for non-reliable transmission of ACKs (comment, J.K.) • The intention is to make delay reduction possible by not using link layer ARQ for acks. • This means that the HC scheme must provide some robustness capabilities for ACKs (see above).

  5. Open issues and comments received, 2(2) • Residual BER?? • How do we handle residual BER for TCP? • Error propagation (2.3-2) could be split in two sections, loss propagation and damage propagation • ECN • Can someone volunteer to provide a suitable input regarding ECN concerns? • Should we require that the TCP profile MUST be IPR free?

  6. How to proceed • Let us discuss the remaining issues on the mailing list in separate threads • An updated version out before April 13th • A stable version ready before London IETF (August)

More Related