2.7.12 Performance Implications of Link Characteristics (pilc)

NOTE: This charter is a snapshot of the 47th IETF Meeting in Adelaide, Australia. It may now be out-of-date. Last Modified: 03-Feb-00


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:



Submit Internet-Draft on significantly low bandwidth links.



Submit Internet-Draft on significantly lossy links.



Submit Internet-Draft on long-thin networks (based on draft-montenegro-pilc-ltn-01.txt) submitted to the IESG for publication.



Draft of link-layer design considerations document.



Draft of PEP capabilities and limitations document.



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.


No Request For Comments

Current Meeting Report

Aaron opened the meeting at 2:15PM on 3/28/00
Went over the agenda, with no comments.

Defered discussion of assymetric draft, since authors are not at this meeting

WG status:

- Submitted "Long Thin Networks" to IESG in October 99
- Should submit PEP draft as informational to IESG by Nov 00
- ASYM document needs more discussion on the list
- Aaron: ASYM will go away if there is consensus that these mechanisms are not needed
- Should submit LINK draft to IESG by Nov 00
- SLOW and ERROR are expected to become BCPs during spring 2000, now in last call

John Border gave the status on the PEP draft:

- The -01 draft missed the DC meeting deadline but was submitted after DC meeting. For the -00 we got valuable comments, but for -01 we didn't get any commnets; maybe as a result of being late?

- Looking for input in the following sections
- protocol booster mechanisims
- ACK filtering and regeneration
- Partial ACK mechanisims
- Others??

- Some additional example environments where PEPs are in use may be added, but only if they illustriate new types or mechanisms not already covered.

- Need help on completing the section on WAP

- Mainly looking for input on implications of using PEPS
- End-to-end failure diagnostics
- Multi-homing environments
- QoS transparency
- Security implications
- Others?

Need further terminology refinment


??: Can get more information on the WAP section from the IAB worksop BOF and plenary WAP discussion

John?: Some problems between asym and pep draft as what happens to ASYM is not known

John Border: Leave specific information in asym draft, if it doesn't go away

Aaron Falk: ASYM will go away if the mechanisims are not real and needed PEP document should only contain mechanisims that are used or are going to be used, and not just academic mechanisims

John Border: We have to draw the line somewhere

??: Are web caches considered peps?

John Border: There is a fine line to whether they are peps or not

Markku Kojo: They are considered PEPs in this doc only when they are related to specific link characteristic(s), i.e. they use some specific mechanisms to mitigate problems due to link behavior

Phil Karn gave the status on the link draft:


- Goal of document is to give advice to designers of subnetworks that intend to carry IP
- Emphasis on end-to-end model, awareness of inter-layer interactions, and eliminating redundancy (between what IP already provides and what link designers are providing)

01 draft submitted for nov99 IETF
- Changes include: address delays, MTUs, error recovery, connection-oriented subnetworks, framing, Bandwidth on Demand

02 was submitted for this IETF
- Reflects current versions of mailing list comments
- Added congestion and flow control QoS, multicast, etc.

- Changes to the current draft (since -01)
- refinement of all sections esp those on impacts on net asym
- end to end philosophy
- all sections related to fundamental link design
- added sections
- QoS management and flow control have some redundent parts compression
- mobility
- broadcast/multicast
- Sections needing work
- QoS & Congestion Control
- Delay and delay variance characteritics
- routing & mobility
- (how much routing should IP provide and how much should the subnetwork provide?)
- multicast support
- QoS management
- next steps
- revisit draft
- seek advice and agree on end to end (QoS ?)

Jamashid: How much delay can a subnetwork add? If many people all take the same advice then the delay can addup

Phil Karn: No one is adding gratituas delay; give us hooks to tell whether the pkt is delay sensitive

??: Connection oriented subnetworks section is biased might want to look at MPLS (MPLS introduces some connection-orientinesh to nets)

Phil Karn: The section advises one to avoid connection oriented subnetworks, some of these topics should be added to congestion management section

Aaron Falk: This is a really important document, and now is the time to add new sections or add/correct current sections, since the document is maturing

Phil Karn: The more people that add to the document, the more credibility it will have

Jamashid: Is there some way to add a short summary of key points

Phil Karn: Thinks this is a good idea, since some sections are long

??: What about FDDI switches that fragment IP packets

Phil Karn: Maybe add this as an example

Gabe Montenagro gave the status of the SLOW and ERROR drafts

- Most of the changes are cosmetic
- Changed from explicit corruption notification to explicit transmission error notification in error draft
- New section were added in both drafts to separate:
- recommended mechanisms
- topics for further work
- Both drafts are currently in last call till april 7

- Issues with SLOW draft (as seen by the authors)
- Need to redo receive and router buffer size example in section 2.3 and address the issues related to the router buffer size more clearly
- Should we reccomend RED? (we think yes)
- Should we recomment ECN?
- Need to beef up MTU section, maybe steal some of link text

- Issues with ERROR draft (as seen by the authors)
- Need editing on section 1.2 (relationship with LINK draft)
- Section 2.2 on AIMD is not accurate
- Section 2.2, why cwnd remains small:
- #2 is inaccurate
- #3 must be removed, cannot be generalised, applies LTNs only
- Need to update section 4.0
- on SACK-EXT as it is no onger experimental
- Delayed DUPACKs section needs clarification

- Some changes are desirable in both drafts
- Do we need a second last call?
- Aaron: if the changes are substantial


Phil Karn: The wording may not carry over from link document, since audiences are different (on whether duplicating text, using pointers to other pilc docs)

Aaron and John: Said that we should make it clear that the topics for further work in appendicies are not part of the recommendations

Gabe Montenagro: Maybe a paragraphs stating that the appencicies are not the emphasis of the document

Geoff Huston: Should say active queue management is important and use RED as an example of this


Advice for Internet Subnetwork Designers
PILC: Performance Enhancing Proxies (PEPs)
SLOW and ERROR Updates (rev 03) draft-ietf-pilc-slow-03.txt
Performance Implications of Link Characteristics (pilc)