Performance Implications of Link-layer Characteristics (PILC) Minutes November 10, 1999, Washington, DC WG chairs: Spencer Dawkins, Aaron Falk Reported by Jim Griner (mailto:jgriner@grc.nasa.gov) and Tim Schweitzer (mailto:tim.schweitzer@nortelnetworks.com) Charts and documents are available from the PILC Web page at http://pilc.grc.nasa.gov. Aaron Falk opened the meeting at 3:30pm and reviewed the agenda, which was accepted without comments. He stated the LINK draft would not be discussed in detail, since the editor of the draft, Phil Karn, was not in attendance at this IETF. Aaron then gave a status of the working group. Most of the documents should be completed by the March IETF, except for the LINK draft which should be completed by July, and the "TCP Over Wireless" draft, which has been deferred until critical sections of SLOW, ERROR, and PEP have been reviewed. Aaron also solicited for contributors to certain sections of the link draft. These sections are: Quality of Service, Fairness Vs Performance, Congestion signaling, Delay Characteristics, Buffering, flow & congestion control, Mobility, Multicasting (has already been started), Routing, Security. Interested contributors should contact Phil Karn directly, at mailto:karn@qualcomm.com. Aaron's presentation is available at http://pilc.grc.nasa.gov/pilc/meetings/dc/pilc-status.pdf. ASYMMETRIC PATHS draft: Venkata Padmanabhan presented the asymmetry draft. Venkata's presentation is available at http://pilc.grc.nasa.gov/pilc/meetings/dc/pilc-asym.pdf. Joe Touch: By compressing ACKs you may be putting all your eggs in one basket, if ACKs are subsequently lost. Venkata Padmanabhan: ACK compression is more susceptible to ACK loss but it is not all or nothing. Van Jacobson: Link-level fragmentation is in the PPP spec. IPSEC with header compression is in RFC2507. Twice algorithm is not limited to single loss. It can be used multiple times, up to 16 packets. Metacomment: Van indicated he had a problem with all PILC documents. He thought they were supposed to be guidance documents to link and protocol designers. He also thought we should be giving boundary criteria, and not just academic references. Using header compression and preserving the entire ACK stream is more robust. Aaron: One PILC document is to give advice to link designers working on link technologies that haven't been deployed yet, while the other documents are to show and scope the problems with already-deployed "challenged" links and to propose solutions to these problems. Van Jacobson: This might not be the best advice to designers, due to different motivations for the development of these academic solutions. Van Jacobson: RFC 1144 header compression, in one-byte mode (as opposed to five-six-byte mode), handles 3000:1 asymmetry. Are we seeing connection paths that are more asymmetric than this? What's the point? Aaron: Points are well taken, and we will take this to the list. Authors should take note of Van's comments. SLOW and ERROR drafts: Spencer Dawkins gave the status of both the slow and error drafts. Spencer's presentation is available at http://pilc.grc.nasa.gov/pilc/meetings/dc/slow-error.pdf. Matt Mathis: Can we use negotiated timestamps at other times other than on SYNs? This may require major RFC1323 changes, but the code changes are trivial. Vern Paxson: This is not in PILC's scope. It can be submitted an individual ID, but not a PILC draft. Matt Mathis: Can we put text about these changes in the SLOW draft? Van Jacobson: The SLOW draft should not contain anything about timestamps! ??: The SLOW draft implies that 296 is a good default MTU for dialup. Spencer Dawkins: It needs to say that 296 is a COMMON MTU for dialup. Gabriel Montenegro: The link draft goes into an MTU discussion. Maybe we should merge these MTU discussions into one draft. Spencer Dawkins: We need to make sure that the recommendations are in the right place(s), and that they are consistent. Aaron Falk: The intent of the LINK document is to guide designers of new links for internet traffic. It is probably appropriate for an MTU discussion in both drafts. Van Jacobson: If there are interactions among parameters, they should be in the LINK draft. Designers try to improve errors, but this in turn significantly increase delay in some links. Don't look at parameters (error, delay, etc) individually. Van Jacobson: In the ERROR draft, very early in the draft, there should be a paragraph on the TCP throughput equation. "Here's how to find out if you need to read further". Designers should do the equation, measure actual throughput, and see if errors really matter in each case. If errors do not have a significant impact on throughput, then don't make any changes. Spencer: Concurred with Van's comments. Aaron: The text in the docs touch on this, but should be expanded. PEP draft - John Border gave a status update on the PEP draft. John's presentation is available at http://pilc.grc.nasa.gov/pilc/meetings/dc/pep-draft-1199.pdf. The latest PEP (01) draft did not make the cutoff for this IETF. It will be released with minor changes after this IETF. Another draft will be ready by March. ??: Does WAP (Wireless Application Protocol) belong in the document? Markku Kojo: As authors, this is also our question! ??: WAP doesn't use IP on one end. Gabriel Montenegro: WAP gateways are very large PEPs. WAP doesn't specify Internet Protocols, but they are layering this on top of the Internet. WAP is THE hot topic for PEPs these days.