Performance Implications of Link-layer Characteristics (PILC) Working group chairs: Spencer Dawkins (mailto:sdawkins@nortelnetworks.com) Aaron Falk (mailto:afalk@panamsat.com) Reported by: Anne Owen (mailto:owen@nortelnetworks.com) Home and mailing list contact information: http://pilc.grc.nasa.gov/pilc MINUTES: The first PILC workgroup meeting was held July 12, 1999 from 7:30 to 10:00 p.m. at IETF 45 in Oslo, Norway. Aaron Falk, WG co-chair, kicked off with a short presentation on the PILC charter (charter is http://www.ietf.org/html.charters/pilc-charter.html, presentation is http://pilc.grc.nasa.gov/pilc/meetings/oslo/status.pdf), reminding us that the PILC charter is to focus first on existing standards, then looking at new technologies if existing standards can't provide acceptable performance. PILC was responsible for delivering five I-Ds by IETF 45. Four of the five have been produced. The fifth, on asymmetric connections, has been delayed. Aaron and Spencer view the remaining PILC milestones as ambitious but (barely) achievable, and Aaron asked the WG assemblage to consider an interim meeting (before IETF 46 in early November). Comments should be sent to the PILC list. Spencer Dawkins presented feedback that has been received on the PILC SLOW I-D (http://www.ietf.org/internet-drafts/draft-ietf-pilc-slow-00.txt, presentation at http://pilc.grc.nasa.gov/pilc/meetings/oslo/slow.pdf). This draft has a simple outline - don't send bits you don't have to send; use compression so you don't have to send them. Recent comments are focusing on strategies for sending "the right bits" first (class-based queuing, etc.) Comment: Some discussion about whether TCP timestamps should be recommended over challenged links or not. The draft will be edited to include this discussion. Comment: This draft should reflect applicable recommendations from ISSLL, especially the ISSLOW work. Comment: This draft should distinguish between what's done for low-bandwidth and what's done for small window sizes. Spencer Dawkins presented feedback that has been received on the PILC ERROR I-D (http://www.ietf.org/internet-drafts/draft-ietf-pilc-error-00.txt, presentation at http://pilc.grc.nasa.gov/pilc/meetings/oslo/error.pdf). This draft is limited in scope, because there's not a way to tell the difference between congestion loss and corruption loss without using intermediate nodes, which are discussed in the PEP draft. Phil Karn presented the LINK draft (http://people.qualcomm.com/karn/pilc.txt). The purpose of this draft is to "reconnect the disconnect" between subnet designers and the IP community. There are several sections of the document which still need text (and, in some cases, authors to contribute text): "QoS, fairness versus performance, and congestion signaling", "delay characteristics", and "buffering, flow and congestion control". Phil also identified "green field" areas that need to be written: mobility, broadcast and discovery, routing, and security. Interested co-authors are solicited - contact Phil at mailto:karn@qualcomm.com to volunteer. Phil pointed out that most often, link layers do too much (repeating functionality that is also provided at higher layers), but that there are a couple of areas where link layers do too little (multicast, QoS). Comments: Asymmetry isn't the only problem for cable modems - there's a one-ACK-per-polling cycle restriction, so that it's very difficult to send ACKs "upstream". This reduces the benefit of ACK compression. Comment: There are a lot of GET requests, in addition to ACKs, in upstream traffic. It's possible to swamp ACKs on cable modems when you are retrieving all the resources on an HTML page. Comment: We need link-level support for IP packet length, because we can't use the IP header length information if the header is compressed. Comment: We need large MTUs for digital signatures. Comment: Links like RLP and ATM are going to do fragmentation, but this shouldn't be visible to IP protocol implementations. Markku Kojo presented the recently-submitted PEP I-D (http://www.ietf.org/internet-drafts/draft-ietf-pilc-pep-00.txt, presentation at http://pilc.grc.nasa.gov/pilc/meetings/oslo/pep.pdf). Markku believes that most of the work remaining on this draft is in the PEP Environment examples (filling in the blanks). Comment: Lots of people who should contribute to the PEP work don't know that PILC exists. Comment: The draft should include the effect of multi-homing environments on PEPs. Comment: The draft should include QoS transparency implications. Comment: The draft should reflect (co-chair's editorial comment - as far as is reasonable) terminology from the glossary in the WREC taxonomy draft (http://www.ietf.org/internet-drafts/draft-ietf-wrec-taxonomy-01.txt) and the (soon-to-be-released) WREC known problems draft. Mikael Degermark presented an overview of current work in header compression CRTP (http://search.ietf.org/internet-drafts/draft-degermark-crtp-cellular-00.txt) and ROCCO (http://search.ietf.org/internet-drafts/draft-jonsson-robust-hc-00.txt), as a heads-up on work that is being done in AVT (presentation at http://pilc.grc.nasa.gov/pilc/meetings/oslo/header-comp.pdf). (SLOW should point to this work, but comments on this work should be directed to the authors themselves). Yongguang Zhang presented a proposal for Multi-layer IPSEC. The approach describes implementation changes that could allow IPSEC protocols to be used with PEPs. This material has not yet been reviewed by the IPSEC working group and may be submitted to tf-esp. A white paper can be found at http://www.wins.hrl.com/people/ygz/ml-ipsec/. Yongguang has indicated that he will be submitting this as an Internet draft. GENERAL DISCUSSION: Comment: HTTP is actually often (and counter-intuitively) large requests with small responses (lots of GET header fields, 304 GET responses with no entity bodies), etc. Comment: HTTP servers don't do persistent connections because they don't want to stay open six seconds. Even HTTP/1.1 servers are configured to turn off persistent connections. The motivation is to save own CPU at the cost of network performance. This is the same reason servers don't want to compress on the fly. Comment: A lot of the problems that HTTP persistent connections were intended to solve can also be solved by TCP control block sharing, and we could be doing this today. Comment: The win for HTTP persistent connections is pulling down all the embedded resources in a page, and then closing the connection immediately.