NOTE: This charter is a snapshot of the 45th IETF Meeting in Oslo, Norway. It may now be out-of-date. Last Modified: 15-Jun-99
Chair(s):
Spencer Dawkins <sdawkins@nortelnetworks.com>
Aaron Falk <afalk@panamsat.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Vern Paxson <vern@aciri.org>
Transport Area Advisor:
Vern Paxson <vern@aciri.org>
Mailing Lists:
General Discussion:pilc@grc.nasa.gov
To Subscribe: majordomo@grc.nasa.gov
In Body: subscribe pilc
Archive: http://pilc.grc.nasa.gov/pilc/list/archive/
Description of Working Group:
Erik Nordmark (nordmark@eng.sun.com) is the Technical Advisor.
The Internet network-layer and transport-layer protocols are designed to accommodate a very wide range of networking technologies and characteristics. Nevertheless, experience has shown that the particular properties of different network links can have a significant impact on the performance of Internet protocols operating over those links, and on the performance of connections along paths that include such links. This is especially of concern to the wireless networking community.
The PILC working group will produce several BCP/Informational documents. The first document will discuss considerations for link-layer designers from the perspective of best supporting existing IETF protocols will be produced. The next document will discuss the capabilities, limitations and pitfalls of 'performance enhancing proxies' (PEPs), that is, active network elements that modify or splice end-to-end flows in an attempt to enhance the performance they attain in the face of particular link characteristics. The remaining documents will either discuss the impact and mitigations for a problematic link-layer characteristic (or group of closely related characteristics), or provide overviews of which other PILC documents apply to particular problem domains.
As one of its first work items, the WG will review an existing I-D on considerations for "long, thin" networks (one of the salient characteristics of terrestrial wireless links). This will be published as a preliminary assessment of the problem domain, to be refined by later PILC documents.
All documents will identify which of their considerations remain research topics versus which are established as advanced development. Research topics will be explicitly flagged as not part of any recommendations. All documents will also identify any security implications associated with their considerations.
The working group will also serve as a forum for discussing possible modifications to IETF protocols to improve performance in environments with problematic link characteristics - however, not to the detriment of performance and stability in the general Internet, nor to undermine existing security models.
It is incumbent upon the chairs to ensure that the WG maintains good communications with other groups interested in related technology issues, such as wireless forums.
Goals and Milestones:
May 99 |
|
Submit Internet-Draft on significantly low bandwidth links. |
May 99 |
|
Submit Internet-Draft on significantly lossy links. |
May 99 |
|
Submit Internet-Draft on long-thin networks (based on draft-montenegro-pilc-ltn-01.txt) submitted to the IESG for publication. |
Jun 99 |
|
Draft of link-layer design considerations document. |
Jun 99 |
|
Draft of PEP capabilities and limitations document. |
Jun 99 |
|
Draft on asymmetric network paths. |
Oct 99 |
|
Draft of TCP Over Wireless document to the IESG as BCP |
Nov 99 |
|
Document on low bandwidth links to IESG for publication as BCP. |
Nov 99 |
|
Document on link-layer design considerations submitted for publication as BCP. |
Nov 99 |
|
Document on lossy links to IESG for publication as BCP. |
Nov 99 |
|
Document on PEP capabilities and limitations submitted for publication as Informational. |
Nov 99 |
|
Document on asymmetric network paths submitted to the IESG for publication as BCP. |
Nov 99 |
|
Possible rechartering of WG to address modifications to IETF protocols. |
Internet-Drafts:
· Performance Implications of Link-Layer Characteristics: Slow Links
· Performance Implications of Link-Layer Characteristics: Links with Errors
No Request For Comments
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.
None received.