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
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:
Done |
|
Submit Internet-Draft on significantly low bandwidth links. |
Done |
|
Submit Internet-Draft on significantly lossy links. |
Done |
|
Submit Internet-Draft on long-thin networks (based on draft-montenegro-pilc-ltn-01.txt) submitted to the IESG for publication. |
Done |
|
Draft of link-layer design considerations document. |
Done |
|
Draft of PEP capabilities and limitations document. |
Done |
|
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:
· End-to-end Performance Implications of Slow Links
· End-to-end Performance Implications of Links with Errors
· Performance Enhancing Proxies
No Request For Comments
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
Comments:
??: 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
Comments:
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)