Performance Implications of Link Characteristics (PILC) IETF-49 Summary Minutes Reported by: Jim Griner (jgriner@grc.nasa.gov) Aaron opened with agenda bashing on Friday 12/15/00 at 9:00AM Agenda Agenda Bashing & WG Status (5) Lower layer guidelines for ROHC - Bormann (10) TCP over Wireless - Inamura (5) draft-ietf-pilc-slow-05.txt - Dawkins (5) draft-ietf-pilc-pep-05.txt - Border (10) draft-ietf-pilc-link-design-05.txt - Karn (10) draft-ietf-pilc-link-arq-issues-00.txt - Karn (for Fairhurst, Wood) (10) Alternate perspective from Reiner Ludwig (10) No comments on agenda Aaron gave a working group status: - TCP on errored links has been submitted to IESG for consideration as BCP - Should we take slow, pep and link to last call? - Need to resolve the future of asym. - Need to draft text for TCP over wireless. Aaron gave the status of the asym draft: - At the Washington IETF some concerns were raised that asymmetries shown in the draft were not severe enough to merit working group attention. This lead the work being halted on the draft. - Prior to this IETF, the -01 draft was cleaned up and submitted as -02. This version was a clean-up of the previous draft. A new draft will be submitted after this IETF. - Will be asking on the mailing list if we should continue with this effort, after the next draft. Carsten Borman gave a status of using ROHC for TCP: - Need header compression on IP-Wireless however wireless is lossy - 2508 causes loss propagation on long RTT links There are currently two main work items within the ROHC working group: - ROHC for IP/UDP/RTP - ROHC for TCP In the RTP area there three documents: - lower-layer guidelines - requirements - main RTP ROHC deliverable Why should the ROHC TCP be develop separately? - The ROHC requirements may be less stringent, due to link layer retransmissions. - RFC 2507 is not enough. ROHC is soliciting more input on TCP header compressions. There are currently two drafts: taroc and epic requirements: - Should not disable TCP mechanisms. - Must not generate damaged headers that pass TCP checksum. - Must deal with current and future TCPs. - Want it to work well for short-lived TCP connections. Call for help: - Design must be influenced by link layers. - Needs documented information on underlying link layers. - current version - for the next 5 years - Link layer designers need ROHC TCP information - Develop a lower layer guideline document. - Help with overall ROHC TCP scheme. http://www.dmn.tzi.org/ietf/rohc Hiroshi Inamura gave a status on the proposed TCP over Wireless draft: Why do we need this document? - To add uniformity on TCP implementations in installed base of mobile handsets. - There is also little information on where WAP is going WAP forum is completing TCP specification for handsets based on IETF/PILC recommendations. There has been a lot of effort in this area and we need to document it in a BCP document. Audience comments: Aaron: This is effort similar in form to how the TCP over satellite work started, documenting effects of satellite links (latency, errors, etc.) We need to publish to the list what this document is going to look like, so you can get more input on the document focus areas. Spencer: You might want to show how items within this document are similar to items within other PILC documents. ?: Want more information on how imode works Hiroshi: Imode was already presented in Adelaide plenary session, but will provide this information. ?: Thought imode used transactional TCP Hiroshi: no it uses .... Spencer gave the status of the slow draft: - -05 has some editorial changes, and thinks it is ready for last call Aaron: We have been working on this draft 1 1/2 years and thinks it is ready for last call. A straw poll was conducted... Of the people who have read the draft, they indicated it is ready for last call. No one in attendance who had read the draft objected to it going to last call. ?: Thinks it might need a security section Spencer: That is a good idea. We need to think about it. John Border gave the status of the PEP draft: - There were some changes from -03 to -04 based on comments from the Pittsburgh IETF meeting related to document scope - Reworked the implications sections to make it clearer The PEP draft went for last call in mid October, but didn't receive many comments. The comments were incorporated and were released in the -05 draft. Aaron: Will send it up for last call based on straw poll of the people who had read the draft. Phil Karn gave the status of the link draft. - -04 is essentially done except for the QoS and ARQ debates - Can probably include ARQ text - All remaining sections have been filled in - made a couple of changes in QoS and Packet Reordering New sections since -03 - fairness vs performance - multicasting - routing (IP vs subnet) - delay characteristics - security ARQ delima: - persistent ARQ is good when it speeds up TCP recovery after a long outage - persistent ARQ is bad when it retransmits packets which have already been retransmitted end to end or needlessly - Possibly use high persistence ARQ for TCP,ICMP, UDP based transactions - Use low persistence for RTP/UDP - can be done heuristically but better done with... Audience comments: Dan: sent in a large section for QoS section, but it wasn't adequately incorporated. Wants clarification on what should be in the QoS section. Phil: likes the comment, and thinks we need more clarification ?: Lets leave it out for now, since we don't know what we want to do Phil: Thinks we need to include some text, that way there is some information for future use Aaron: We should not be making recommendations on diffserv issues Phil: Does anyone have a problem with current text? Dan: We need a little bit of a wrapper around the current text. Kathy: Didn't see anything controversial about the text. Dan: RFC 2474 obsoletes the TOS field as we use to know it, and there is a new semantic of these bits for edge to edge use Kathy: One can use the TOS bits in a wide variety of ways, and the draft says how the field use to be used but it doesn't say how they are used now. Just refer to RFC 2474 and RFC 2780 for how they are used now. Dan: The bits are used on hop by hop rather than end-to-end. We shouldn't be overemphasizing those bits. We shouldn't be focusing on this area, but rather more of the overall picture. Aaron: We should be telling link designers how to work with the diffserv and intserv information that is available. Kathy: You just want to refer to the other RFCs on these issues. Dan: will provide some more text Gabe: ECN area should be revised in link draft, since the ECN draft is now going for RFC. Phil Karn gave a presentation on the ARQ issues for IP traffic - We don't aim to categorize ARQ definitely, just to make people aware of what it can do to IP traffic. ---- See presentation for all the details ---- Reiner Ludwig gave a presentation on 'Can wireless preserve the end-to-end argument' - wireless link layers should be flow adaptive How to implement: - use link layer sniffing or a clean layered design Argument: everything should be done at the end-points, but this has been shown to not be the case link layer sniffing is a layer violation, but so is ROHC - Flow-adaptive breaks with IPSEC Link layer ARQ persistency for reliable flows - assume flow-adaptive link layer - assume link layer ARQ is possible - link layer ARQ persistency for TCP? Simply setting the MTU to small enough values and use TCP-SACK does not work. Want to recommend to link layer designers that link layer ARQ should try for up to 64 seconds to transmit a TCP packet - this is not saying unbounded queues - this is not saying to use hop-by-hop reliability instead of end-to-end reliability High delays due to link layer ARQ are very rare, usually they are less than 1 sec, and mainly occur during link outages This is the most spectrum end energy efficient method. Discarding a packet that has made it 90% across the link is not efficient. Provides robustness against link outages There are concerns about spurious retransmissions, inflated RTO, head of line blocking, but these are all easily solved. Flow-adaptive Link layer and high persistent link layer ARQ for TCP eliminates non congestion TCP losses and eliminates the need for a proxy No need for robustness in TCP/IP header compression scheme, and VJ header compression will work just fine. Phil Karn: the 64 second time could be eliminated if there was an expiration on the packet Ludwig: yes, we should use TTL in ms. Carsten Borman: Likes the idea of determining flow differences, in reference to determining how robust the header compression should be. Ludwig: With TTL in ms and an idea of what the application wants, we could do a lot. Carsten Borman: We can't just look at the links, since some links may not be persistent Ludwig: doesn't buy this argument. Karn: Disagrees with slow draft that timestamps should be avoided Aaron: The slow draft is targeted towards legacy links Karn: Thinks there was disagreement between slow and link ?: Can you just look at TOS field to determine flow information Ludwig: With IPSEC the DS field is the only that is not encrypted Dan: Are you sure you want to do front dropping Ludwig: This is the fastest way to signal TCP Markku: Doesn't agree with elimination of head of line blocking problem Ludwig: Cannot allow a flow that has trouble to be taking up all the queue space. We should take this off-line Carsten Borman: --Put up a TCP throughput equation, to show there is a RTO component-- Ludwig: Doesn't have a good answer, since this is a research topic (for developing this equation) since it was developed for a high degree of multiplexing and not for a low degree of multiplexing that we have here. We shouldn't be so scared of spurious timeouts. You have to pay for your poor link at some point. Aaron: Need to think about this more, before we put it in a document. Take this to the list for more discussion. Ludwig: Thinks we already have consensus on these issues Aaron: Before we make this recommendation we should talk about it on the list Ludwig: We are not going to make specific recommendation on how to separate flows. But if you can't do this, then don't follow the additional recommendations. Spencer: Might want to list alternatives to help the discussion on the list. The meeting was adjourned at 10:50. Jim Griner