2.6.11 Performance Implications of Link Characteristics (pilc)

NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00


Spencer Dawkins <spencer_dawkins@fnc.fujitsu.com>
Aaron Falk <afalk@panamsat.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@east.isi.edu>

Transport Area Advisor:

Allison Mankin <mankin@east.isi.edu>

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

Performance Implications of Link-layer Characteristics (PILC) Minutes
August 2, 2000, Pittsburgh, PA

Reported by Jim Griner (jgriner@grc.nasa.gov)
Edited by Aaron Falk (aaron@panamsat.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,
Agenda bashing, with no comments

milestones & status

TCP over Wireless draft. The working group charter specifies that PILC will produce a 'TCP over Wireless' RFC that is a meta list of the existing PILC recommendations. This was reported in Adelaide as being completed in October 1999 because Aaron had confused it with the LTN draft. Actually, it requires some work. Gabe Montenegro has volunteered to sync up with the WAP forum to see if we can build this document on a work in progress that already exists in that body. The document should be only 3 or 4 pages long and should go to wg last call by January 2001. Gabe noted that there is currently no buy in by the WAP forum as yet, he will attend a forum meeting in September and try to resolve. Several members of WAP were in the room and volunteered to assist if needed.

ERROR draft. A rough poll was taken indicating the group felt ERROR was ready for wg last call.

SLOW draft. One of the SLOW authors wanted to incorporate some additional comments before submitting the draft for wg last call. When polled, there was no clear consensus of the group. Will see what comments come up on mail list during last call. Last call should take place in September. There was some discussion about interactions between slow and errored networks and that there should be a way to document interactions when you have multiple characteristics in a network. In particular, it was pointed out that these interactions are not well understood. However, most of the understood ones exist in some of the PILC documents (ERROR, SLOW, and LINK). It was suggested that appropriate cross references be added to ensure readers of one document are aware of relevant interactions described in another document. Suggested this issue gets raised on the list to see if there are interactions that need to be captured somewhere. (Some interactions were captured in RFC2488 but these are appropriate for all environments since that document focuses on long delay links.)

Updated Working Group Milestones

Aug 2000: ERROR (BCP) to working group last call
Sep 2000: SLOW (BCP) to working group last call
PEP (Informational) to working group last call
Nov 2000: LINK (BCP) to working group last call
Jan 2001: TCP over Wireless (BCP) to working group last call

Note: ASYM is in limbo right now until we get an updated draft.

Phil Karn - LINK document status

Placing emphasis on end-to-end model. The multicast section is still incomplete. Didn't add much to this revision of the document. Assymetry section overlaps with asym draft. May rip out section on QoS because there may not be much well understood advice that can be given. Document still needs text on:

Comments: Dan Grossman thinks there is some parts of QoS that are not overlapping with diff serv, and will provide some text.

John Border - PEP document status
Didn't receive many comments on -02 draft. Draft-03 released prior to this meeting. A disclaimer was added to say it is an overview document and does not include all PEP mechanisms. Document needs text on:

Plan next release (-04 draft) at end of September

Aaron - PEP comments

PEPs are being used in many environments, and we ignore them at our peril. One reason this document is being written is that we need to show what the downsides are to using peps. Outside organizations who are using these types of mechanisms (such as WAP) are being directed to pilc by the IESG so that they can understand how the IETF views these mechanisms. The PEP document is the place to show the problems of using PEPs. We need more information from members of the working group to add to the document. Specifically, we have not received adequate comments from an architectural perspective. Geoff pointed out that things like multi-homing are being used as a surrogate for reliability.

Joe Touch suggested to limit PEP document to IP layer discussions, rather than the link layer problem. John Border noted that we were deferring link layer mechanisms to the link document, due to the scope of pep. There was also a comment mentioning that PEPs are being used to put QoS in wireless links, and maybe need to include this in PEP.

Discussion on DoCoMo draft (draft-inamura-docomo-00.txt)

Aaron noted that DoCoMo would like to publish this as informational RFC, but we don't want to get in a mode of publishing RFCs each time someone does this and requested input from the group.

A speaker noted that the recommendations are pretty generic and suggested the working group use this as a starting point for the TCP over wireless document, or as an appendix to this document. Aaron suggested it might be necessary to take the simulation results out in order to use this document for the TCP over wireless document. Another speaker suggested using path MTU discovery instead of fixing it at 1500. Question: Maybe your tcp stack in the Opnet simulator is not the best TCP. Have you run this on real stacks, rather than on a simulator. Imaura - yes they have, but no published results.

Aaron noted that another alternative was that the DoCoMo would be sent forth as informational, and would not be a recommendation. Tim Shepard asked why would one want to disseminate this information?
Doesn't seem to make sense to have multiples of TCP/some link technology. Is this advice on how to tune TCP for the handset?
Response from author: yes.

Comment: This shows that tcp stack works over wireless error prone links.

Comment: Doesn't think these results are any different from what a modern TCP stack does anyway.

Gabe: This is similar to what was done in ecn document

Comment: Thinks this should be published in academic journals, and not as an RFC

Question: What bandwidth was used in the simulations?
Imaura: 384kbs
Comment: Doesn't think this is realistic, since this is only the rate if you are the only one in the cell. WAP is designed to use slower links.

Discussion on Long lived TCPs draft (draft-magret-pilc-lltcp-00.txt)

Comment: this is probably not a good idea -- leads to ICMP flooding. Also, if there is a long outage you do want to go through slow start again, because the network has changed. There are better link level solutions to this problem.

Question: Why do you need a proxy and not just use end-to-end signaling?
Response: The supervisor is in a better position to determine if there is an interruption.
Response: In this case you need a proxy, and can't do it end-to-end.


Long-Lived TCP
Status Summary
A TCP profile for W-CDMA: 3G wireless packet service