Performance Implications of Link Characteristics (PILC) BOF Summary
Minutes reported by: Jim Griner (
[email protected])
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.
Open Issues:
Don't understand PEPs very well.
Unambiguous loss due to errors.
RTT interactions with handoffs.
Questions:
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.
Mitigation techniques:
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
Issues:
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
possible directions:
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.
Challenges:
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.
Misplaced Priorities:
Missing stuff - multicast, deployment - get it out there
quickly
Less than totally useless - short messaging
Other Issues:
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.
