NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 11-Oct-00
Chair(s):
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:
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
· Advice for Internet Subnetwork Designers
No Request For Comments
Performance Implications of Link Characteristics (PILC) IETF-49 Summary Minutes
Reported by: Jim Griner (jgriner@grc.nasa.gov)
Aaron opened with agenda bashing on Friday 12/15/00 at 9:00AM
Agenda
Agenda Bashing & WG Status (5)
Lower layer guidelines for ROHC - Bormann (10)
TCP over Wireless - Inamura (5)
draft-ietf-pilc-slow-05.txt - Dawkins (5)
draft-ietf-pilc-pep-05.txt - Border (10)
draft-ietf-pilc-link-design-05.txt - Karn (10)
draft-ietf-pilc-link-arq-issues-00.txt - Karn (for Fairhurst, Wood) (10)
Alternate perspective from Reiner Ludwig (10)
No comments on agenda
Aaron gave a working group status:
- TCP on errored links has been submitted to IESG for consideration as BCP
- Should we take slow, pep and link to last call?
- Need to resolve the future of asym.
- Need to draft text for TCP over wireless.
Aaron gave the status of the asym draft:
- At the Washington IETF some concerns were raised that asymmetries shown in the draft were not severe enough to merit working group attention. This lead the work being halted on the draft.
- Prior to this IETF, the -01 draft was cleaned up and submitted as -02.
This version was a clean-up of the previous draft. A new draft will be submitted after this IETF.
- Will be asking on the mailing list if we should continue with this effort, after the next draft.
Carsten Borman gave a status of using ROHC for TCP:
- Need header compression on IP-Wireless however wireless is lossy
- 2508 causes loss propagation on long RTT links
There are currently two main work items within the ROHC working group:
- ROHC for IP/UDP/RTP
- ROHC for TCP
In the RTP area there three documents:
- lower-layer guidelines
- requirements
- main RTP ROHC deliverable
Why should the ROHC TCP be develop separately?
- The ROHC requirements may be less stringent, due to link layer retransmissions.
- RFC 2507 is not enough.
ROHC is soliciting more input on TCP header compressions. There are currently two drafts: taroc and epic
requirements:
- Should not disable TCP mechanisms.
- Must not generate damaged headers that pass TCP checksum.
- Must deal with current and future TCPs.
- Want it to work well for short-lived TCP connections.
Call for help:
- Design must be influenced by link layers.
- Needs documented information on underlying link layers.
- current version
- for the next 5 years
- Link layer designers need ROHC TCP information
- Develop a lower layer guideline document.
- Help with overall ROHC TCP scheme.
http://www.dmn.tzi.org/ietf/rohc
Hiroshi Inamura gave a status on the proposed TCP over Wireless draft:
Why do we need this document?
- To add uniformity on TCP implementations in installed base of mobile handsets.
- There is also little information on where WAP is going
WAP forum is completing TCP specification for handsets based on IETF/PILC recommendations. There has been a lot of effort in this area and we need to document it in a BCP document.
Audience comments:
Aaron: This is effort similar in form to how the TCP over satellite work started, documenting effects of satellite links (latency, errors, etc.) We need to publish to the list what this document is going to look like, so you can get more input on the document focus areas.
Spencer: You might want to show how items within this document are similar to items within other PILC documents.
?: Want more information on how imode works
Hiroshi: Imode was already presented in Adelaide plenary session, but will provide this information.
?: Thought imode used transactional TCP
Hiroshi: no it uses ....
Spencer gave the status of the slow draft:
- -05 has some editorial changes, and thinks it is ready for last call
Aaron: We have been working on this draft 1 1/2 years and thinks it is ready for last call.
A straw poll was conducted... Of the people who have read the draft, they indicated it is ready for last call. No one in attendance who had read the draft objected to it going to last call.
?: Thinks it might need a security section
Spencer: That is a good idea. We need to think about it.
John Border gave the status of the PEP draft:
- There were some changes from -03 to -04 based on comments from the Pittsburgh IETF meeting related to document scope
- Reworked the implications sections to make it clearer
The PEP draft went for last call in mid October, but didn't receive many comments. The comments were incorporated and were released in the -05 draft.
Aaron: Will send it up for last call based on straw poll of the people who had read the draft.
Phil Karn gave the status of the link draft.
- -04 is essentially done except for the QoS and ARQ debates
- Can probably include ARQ text
- All remaining sections have been filled in
- made a couple of changes in QoS and Packet Reordering
New sections since -03
- fairness vs performance
- multicasting
- routing (IP vs subnet)
- delay characteristics
- security
ARQ delima:
- persistent ARQ is good when it speeds up TCP recovery after a long outage
- persistent ARQ is bad when it retransmits packets which have already been retransmitted end to end or needlessly
- Possibly use high persistence ARQ for TCP,ICMP, UDP based transactions
- Use low persistence for RTP/UDP
- can be done heuristically but better done with...
Audience comments:
Dan: sent in a large section for QoS section, but it wasn't adequately incorporated. Wants clarification on what should be in the QoS section.
Phil: likes the comment, and thinks we need more clarification
?: Lets leave it out for now, since we don't know what we want to do
Phil: Thinks we need to include some text, that way there is some information for future use
Aaron: We should not be making recommendations on diffserv issues
Phil: Does anyone have a problem with current text?
Dan: We need a little bit of a wrapper around the current text.
Kathy: Didn't see anything controversial about the text.
Dan: RFC 2474 obsoletes the TOS field as we use to know it, and there is a new semantic of these bits for edge to edge use
Kathy: One can use the TOS bits in a wide variety of ways, and the draft says how the field use to be used but it doesn't say how they are used now. Just refer to RFC 2474 and RFC 2780 for how they are used now.
Dan: The bits are used on hop by hop rather than end-to-end. We shouldn't be overemphasizing those bits. We shouldn't be focusing on this area, but rather more of the overall picture.
Aaron: We should be telling link designers how to work with the diffserv and intserv information that is available.
Kathy: You just want to refer to the other RFCs on these issues.
Dan: will provide some more text
Gabe: ECN area should be revised in link draft, since the ECN draft is now going for RFC.
Phil Karn gave a presentation on the ARQ issues for IP traffic
- We don't aim to categorize ARQ definitely, just to make people aware of what it can do to IP traffic.
---- See presentation for all the details ----
Reiner Ludwig gave a presentation on 'Can wireless preserve the end-to-end argument'
- wireless link layers should be flow adaptive
How to implement:
- use link layer sniffing or a clean layered design
Argument: everything should be done at the end-points, but this has been shown to not be the case
link layer sniffing is a layer violation, but so is ROHC
- Flow-adaptive breaks with IPSEC
Link layer ARQ persistency for reliable flows
- assume flow-adaptive link layer
- assume link layer ARQ is possible
- link layer ARQ persistency for TCP?
Simply setting the MTU to small enough values and use TCP-SACK does not work.
Want to recommend to link layer designers that link layer ARQ should try for up to 64 seconds to transmit a TCP packet
- this is not saying unbounded queues
- this is not saying to use hop-by-hop reliability instead of end-to-end reliability
High delays due to link layer ARQ are very rare, usually they are less than 1 sec, and mainly occur during link outages This is the most spectrum end energy efficient method. Discarding a packet that has made it 90% across the link is not efficient. Provides robustness against link outages
There are concerns about spurious retransmissions, inflated RTO, head of line blocking, but these are all easily solved.
Flow-adaptive Link layer and high persistent link layer ARQ for TCP eliminates non congestion TCP losses and eliminates the need for a proxy No need for robustness in TCP/IP header compression scheme, and VJ header compression will work just fine.
Phil Karn: the 64 second time could be eliminated if there was an expiration on the packet
Ludwig: yes, we should use TTL in ms.
Carsten Borman: Likes the idea of determining flow differences, in reference to determining how robust the header compression should be.
Ludwig: With TTL in ms and an idea of what the application wants, we could do a lot.
Carsten Borman: We can't just look at the links, since some links may not be persistent
Ludwig: doesn't buy this argument.
Karn: Disagrees with slow draft that timestamps should be avoided
Aaron: The slow draft is targeted towards legacy links
Karn: Thinks there was disagreement between slow and link
?: Can you just look at TOS field to determine flow information
Ludwig: With IPSEC the DS field is the only that is not encrypted
Dan: Are you sure you want to do front dropping
Ludwig: This is the fastest way to signal TCP
Markku: Doesn't agree with elimination of head of line blocking problem
Ludwig: Cannot allow a flow that has trouble to be taking up all the queue space. We should take this off-line
Carsten Borman: --Put up a TCP throughput equation, to show there is a RTO component--
Ludwig: Doesn't have a good answer, since this is a research topic (for developing this equation) since it was developed for a high degree of multiplexing and not for a low degree of multiplexing that we have here. We shouldn't be so scared of spurious timeouts. You have to pay for your poor link at some point.
Aaron: Need to think about this more, before we put it in a document. Take this to the list for more discussion.
Ludwig: Thinks we already have consensus on these issues
Aaron: Before we make this recommendation we should talk about it on the list
Ludwig: We are not going to make specific recommendation on how to separate flows. But if you can't do this, then don't follow the additional recommendations.
Spencer: Might want to list alternatives to help the discussion on the list.
The meeting was adjourned at 10:50.
Jim Griner
Performance Enhancing Proxies Document
ROHC Robust Header Compression
Project to Write a PILC BCP RFC
Link ARQ Issues for IP Traffic
'draft-ietf-pilc-error-06'
Performance Implications of Link Characteristics (PILC)
Can Wireless Preserve the E2E Argument ?