Performance Implications of Link Characteristics (PILC) BOF Summary
Minutes reported by: Jim Griner (firstname.lastname@example.org)
The Performance Implications of Link Characteristics BOF was held on December 9th at 9AM. Aaron Falk, BOF co-chair, presented background, history, and motivations for having a PILC BOF. Items discussed by Aaron follow:
(1) TCP/IP works over almost any link type, but there are performance implications caused by certain link characteristics.
(2) TCPSAT was a good start, but because of its limited scope (long delay links) many questions which were raised about other link types could not be adequately discussed.
(3) Why do we need a working group? The IETF needs to understand the impact of link characteristics on end-to-end performance, so that protocols can take the link characteristics into account or that the links can be better designed for the protocol.
Next, a number of presentations were given to highlight the impact various link layer characteristics have on upper layer protocols.
Spencer Dawkins, Nortel, discussed characteristics and implications of long-thin-noisy links.
Problems: windows open slowly, windows don't remain open, handoffs, poor throughput costs money, bitrates are getting faster in cellular but have to wait on TCP (delay)
Long thin Networks today:
- Implement recommendations from TCPSAT.
- Use research topics from TCPSAT.
- Insert PEPs.
- Abandon TCP in some cases over wireless links.
- Don't understand PEPs very well.
- Unambiguous loss due to errors.
- RTT interactions with handoffs.
- Can we have only one TCP?
Rod Ragland, Hughes, discussed characteristics and implications of long-fat-asymmetric links.
Factors affecting TCP throughput in challenging environments:
- Network response times.
- Personal Earth Station, inroute and outroute speeds.
- Window size limits throughput.
- TCP Spoofing
- Web Caching
- Ack Filtering and Congestion Control
- Data Compression
Matt Mathis, Pittsburgh Supercomputing Center, discussed interactions between FDDI and 10BaseT networks.
- Time-Sequence plots showing FDDI interaction with 10BaseT, buffer and token effects.
Rohit Goyal, Ohio State University, discussed variable bandwidth and implications on higher layer protocols.
- Wireless - time varying error.
- Mobility - roaming into different bandwidths.
- Shared Media - MAC protocols no sustained bandwidth guarantee.
- Changing Bandwidth-Delay product - difficult for TCP to estimate network capacity
- starvation -> TCP time out
- packets dropped in the middle
- difficult to provide throughput guarantees
- unpredictable quality for video/voice
- TCP based approaches - socket buffer tuning, ssthresh estimation
- Network based approaches - dropping vs. feedback, dropping early vs. dropping late
- Other solutions - bandwidth sharing, traffic scheduling, bandwidth management.
Shiv Kamar, Ohio State University, discussed issues of a core network bottleneck with variability.
Variability in demand or capacity makes matching error prone and difficult - especially for high bandwidth, long delays, large number of sources, and lack of filtering
- reduce variability in capacity
- reduce variability in demand
- shape the traffic
- explicit feedback
Don Hoffman, Teledesic, discussed TCP interactions with Bandwidth on Demand/Demand Assignment Multiple Access networks.
- DAMA - Link protocol for uplinking slot assignment
- Use scarce network resources by bandwidth utilization to actual traffic.
- BoD - Signaling used to request DAMA slots
- Time from request to slot availability can be slow.
- Access Delay - how long until a change of bandwidth becomes effective.
- Queuing Delay - TCP/IP traffic may be queued waiting for access.
- Bandwidth Quantitization - bandwidth in therms of "chunks"
- May exclude IP fragments and results in delay variations.
- TCP/IP transparency to BoD specifics.
- Influence (Interactions) on - slowstart, window sizes, retransmit timeouts, congestion avoidance, fairness between ground stations
- Solutions in space:
- Defining/predicting bandwidth requirements - (non elastic services (RSVP), elastic (TCP))
- Optimization of request/allocation
- Optimization of packets/fragments
Phil Karn, Qualcomm, discussed interactions between the Internet and Telecom companies.
Need IETF document that tells telcos and physical layer designers what they need to know about the Internet.
- Missing stuff - multicast, deployment - get it out there quickly
- Less than totally useless - short messaging
- FEC and ARQ - what is appropriate loss rate
- Latency Matters
- Management of connection oriented channels
- Forget OSI
- resist temptation to violate layering - protect end-to-end
Mark Allman, BOF co-chair, discussed the remaining link types, from the list included in the BOF description. He asked for additions to the list. Suggestions of additions, from the audience follow:
(1) Links where units of loss are not equal to units of retransmission.
(2) Exposure and elimination of link layer stupidity.
(3) Wireless links in the middle of the network
(4) Intermittent outages
- short lived (recoverable)
- long lived (hold back data)
### unidirectional??? (this was on the original list, no?)
(5) Asymmetric (send but not receive)
(6) Links that obscure TCP clocking
(7) Link peak rate limitations ??????
Aaron Falk, BOF co-chair, discussed a possible charter:
(1) Develop informational documents detailing how link characteristics interact with IETF protocols.
(2) Assess modifications or extensions of IETF protocols.
The floor was opened to the audience for discussion. Topics of discussion follow:
(1) A working group is needed, and two documents need to be produced:
- That TCP can do
- What links need to know about TCP
(2) TCP should handle any type of link
(3) TCP may be the wrong place to address these problems
(4) Need to specify between traffic shaping and policing
(5) Need to tell the application guys as well as the link guys about TCP.
(6) Might be useful to go through the list of link types and say where to solve these problems (TCP, link, etc.).
(7) TCP had a specific link in mind during its design. The link needs to be molded to be within acceptable parameters.
(8) TCP has evolved over time. The list is not important. We are just throwing the problems to someone else.
Aaron suggested this group has a unique opportunity to effect link and protocol design/improvements, as well as implementations.
(9) Use network knowledge from routers to help TCP make better decisions, using existing tools.
(10) Use interim solutions (PEPs), since end-to-end changes take a long time.
(11) Internet model's old assumptions may be invalid.
(12) Look at other than TCP solutions.
(13) Is today's discussion really research, which shouldn't be in the IETF.
(14) Middleware may take care of some of the link problems.
(15) Best Common Practices document (suggested earlier in Phil Karn's presentation), would be extremely helpful.
(16) Need to better clarify the link problems on list.
(17) Need to get a focused direction, and maybe form separate working groups. First gain common ground before forming groups.
(18) Kernel changes take a long time to get into end systems, but programs move significantly faster.
(19) PEPs may not all be bad.
(20) Doesn't like uncontrollable proxies, which are invoked without the user's consent.