Internet Draft Spencer Dawkins
Expires: August 2003 Cyneta Networks
Carl E. Williams
MCSR Labs
Alper E. Yegin
DoCoMo USA Labs
Framework and Requirements for TRIGTRAN
draft-dawkins-trigtran-framework-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet
Engineering Task Force (IETF), its areas, and its working
groups. Note that other groups may also distribute working
documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsolete by other
documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as
"work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed
at http://www.ietf.org/shadow.html.
Conventions used in this document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described
in RFC-2119 [ ].
Abstract
IETF-standardized unicast transport protocols have been
designed to allow two end points to maintain communications by
individually reacting to loss or degraded packet arrival times.
Historically, those protocols have assumed loss is congestive
and have reacted by decreasing the packet transmission rate to
ease congestion. There are a number of cases, however, where
these assumptions are incorrect, and one or more path segments
present losses due to intermittent connectivity, a high
uncorrected error rate, or the need for access path changes
("hand-off"s). Previous work [PILC] has addressed these
conditions using end-to-end mechanisms. This draft examines the
use of an on-path signaling mechanisms capable of providing
advisory notifications for use in modifying the behavior of the
transport in order to better respond to actual network
conditions. This draft serves to create discussion in this area
as there are many ways to skin the cat. We are interested in
hearing about them through open discussion.
Dawkins, Williams, Yegin Expires August 2003 [Page 1]
Internet-Draft TRIGTRAN Framework February 2003
List of Abbreviations
TRIGTRAN Triggers for the Transport
AR Access Router
1. Introduction
IETF transport protocol development has been based on the
assumption that two communicating endpoints know more about
characteristics of the paths between these endpoints than any
single device within the network. Because IP datagrams can be
forwarded over a variety of paths between two endpoints, a
device within the network might have detailed knowledge of one
path, but typically does not have detailed knowledge of all
possible paths.
The scope of this work will focus on a framework for providing
information to the transport via triggers of connection path
characteristics. In particular, it is possible that a wireless
access device might provide information about the path in a
useful way because
(a) the wireless access device has detailed knowledge of a sub-
network link, and
(b) it can still communicate with one endpoint when a
problematic sub-network link stops working, or starts working,
or changes its characteristics in some interesting way.
The goal here is that changes in path characteristics,
especially in reachability, can be explicitly signaled
expeditiously, while still relying on transport
acknowledgements and timeouts.
If this goal is accepted, it may be broadened to include other
sub-network events, if these sub-network events are generic in
nature and accepted by the IETF community as a whole.
To further this goal this document will provide a basis of
understanding of the following:
- The nature of generic "transport triggers"
- Possible uses of "transport triggers"
- Mechanisms for signaling transport triggers to accessible
transport endpoints
- The architectural impact of this addition to the transport
layer
Dawkins, Williams, Yegin Expires August 2003 [Page 2]
Internet-Draft TRIGTRAN Framework February 2003
Although the need for this change is more obvious in a wireless
environment, we're also soliciting input from the rest of the
Internet community in these areas:
- Whether there are "transport triggers" applicable to many
sub-network types, beyond link up/link down
- Whether the use of "transport triggers" is worth the effort
of modifying existing transport protocols to make use of this
information
Why TRIGTRAN Isn't Fast Handoff
Transport triggers are similar to, but distinct from, similar
discussions on triggers in MOBILEIP and in IRTF's Routing
Research Group on micro-mobility. The primary difference is the
low latency and tight coupling required for fast handoff. It is
anticipated that the resulting model for defining transport
triggers will provide a framework for future trigger discussion
that are required for IP handoff protocols.
Why TRIGTRAN Isn't Wireless-only or TCP-only
Although TRIGTRAN is initially focusing on TCP connections over
wireless sub-network links, we note that SCTP transports often
have multiple wireline paths between two SCTP hosts for
reliability. We don't want to do anything in TRIGTRAN that
would prevent the use of TRIGTRAN as a notification mechanism
for SCTP switchover - so please keep us honest!
This document describes a general framework and provides for a
requirement list for the TRIGTRAN architecture in terms of
notification events and protocol considerations. In the next
section the authors provide a write-up on TRIGTRAN
justification. This content may well end up in the problem
space draft but the authors would like to include this
discussion here for purposes of the BOF that is planned at IETF
San Francisco.
2. Justification for TRIGTRAN
The variety of devices accessing the Internet, and the variety
of access links they are using, continues to increase. At least
some of these links exhibit characteristics that cause some
Internet protocols, especially TCP [RFC793], to perform poorly.
Among these characteristics are:
1. Intermittent connectivity
2. Access path changes ("hand-offs")
3. High uncorrected error rate
Dawkins, Williams, Yegin Expires August 2003 [Page 3]
Internet-Draft TRIGTRAN Framework February 2003
For example, TCP congestion control [RFC2581] performs well
over paths that lose traffic primarily because of congestion
and buffer exhaustion, but performs poorly when TCP connections
traverse links with high uncorrected error rates. Sending TCPs
spend an inordinate amount of time waiting for acknowledgements
that will not arrive, and then, although these losses are not
due to congestion-related buffer exhaustion, the sending TCP
transmits with a substantially reduced congestion window as it
probes the network to determine its "safe" traffic level.
The root cause here is that TCP sees only one (implicit) signal
about path conditions - packet loss - and can interpret this
signal in only one way. The most conservative assumption is
that packet loss is due to congestion, and for most of TCP's
history, this conservative assumption was correct and
sufficient. When transports traverse paths that include
intermittent connectivity or other non-congestion "challenges",
additional detection mechanisms are required.
TRIGTRAN ("Triggers for Transport") is a follow-up to the body
of work done in the IETF's Performance of Link
Characteristics(PILC) working group [PILC]. In PILC we were
able to examine the specific TCP mechanisms that are
problematic in environments with "challenged" links, and
develop Best Current Practice specifications describing what
can be done to mitigate these problems without introducing
intermediate devices into the connection. PILC established the
limits of "end to end" mechanisms with "challenged" links. With
TRIGTRAN we are looking at advisory explicit notification
("hints") being initiated from an edge router to endpoint
transport implementations across the Internet.
3. Strawman Framework
TRIGTRAN is focusing specifically on the case of problematic
access links, because so many problematic links fall into this
category (although not all problematic links are access links),
and because this is the simplest useful case. More complex
topologies are outside the scope of TRIGTRAN, at least for now.
In a nutshell, the minimal TRIGTRAN architecture looks like:
+------+ +-----------------+ (Internet +------+
| Host | | TRIGTRAN Router | goes | Host |
+------+ +-----------------+ here) +------+
X X
Sub-network Event ------------------> Notifies Transport
Here Here
Dawkins, Williams, Yegin Expires August 2003 [Page 4]
Internet-Draft TRIGTRAN Framework February 2003
The critical feature here is that the host receiving a TRIGTRAN
trigger is across an arbitrary network topology from the
TRIGTRAN edge router sending the trigger. The host receiving
the trigger then takes some transport-level action (sending a
packet, retransmitting a packet, waiting for some period of
time to transmit a packet, etc).
The transports would figure out "most events" eventually, given
enough time (i.e., round trip times). For instance, TCP is good
at figuring at bandwidth changes, but not as good at detecting
a remote link transitioning to the "up" state after a
retransmission timeout. Eventually, a backed-off RTO timer will
fire, and the now-accessible receiver will acknowledge the next
(successful) retransmission, but the sender and receiver will
be waiting when they could be communicating.
TRIGTRAN can give the host receiving triggers hints that it
might reattempt transmission, without waiting a complete RTO
interval. TRIGTRAN is intended to provide network-based hints
that clue the transport in more quickly (where "quickly" is
measured in RTTs, not in milliseconds).
TRIGTRAN triggers are advisory in nature - they do not replace
transport-level mechanisms (in the case of TCP, the receiver's
ACK stream). Indeed, the TRIGTRAN architecture is a continuum
of an existing body of work based on the principle that more
and more often the network can clue a transport in on what is
going on. Previous examples of "network-based clues" include
ICMP Source Quench and Explicit Congestion Notification (ECN).
These methods are a way for the transport to obtain more clues
from the network but without relying exclusively on that
information to function properly.
4. TRIGTRAN Protocol Principles/Considerations
* Transports can request trigger coverage from any adjacent access
router, although only TRIGTRAN-aware access routers will provide trigger
coverage. The host making this request is called the "TRIGTRAN
Initiator".
* Correspondent hosts will request desired trigger notifications
explicitly (they will not be sent to a correspondent host without prior
arrangement).
* Trigger coverage requests and notification requests will be
piggybacked on existing traffic ("setting a bit", not injecting new
packets). The notifications themselves will be injected, of course.
* A TRIGTRAN-capable access router will inject trigger notifications.
The exact structure of the notification is TBD.
Dawkins, Williams, Yegin Expires August 2003 [Page 5]
Internet-Draft TRIGTRAN Framework February 2003
* Triggers are per-host-pair over a specified interface - if a TRIGTRAN
Initiator requests trigger coverage for any packets destined for a
correspondent host, and the correspondent host expresses interest in
receiving triggers, the TRIGTRAN-capable access router will send a
single notification to the correspondent host.
* No reliability mechanism for triggers is defined. If a single trigger
is lost for an event of interest to a transport, the transport will
respond to the event using end-to-end mechanisms.
* TRIGTRAN registrations can be installed in one round trip (from the
point of view of the TRIGTRAN Initiator).
* TRIGTRAN registrations install "soft state". TRIGTRAN Initiators must
repeat coverage requests periodically, and correspondent hosts
requesting trigger notifications must repeat this request periodically.
The periodicity for these requests is TBD, but should be on
the order of five minutes. The TRIGTRAN-capable access router will
expire these requests after three of these time periods have elapsed.
* TRIGTRAN should work even if TRIGTRAN-capable access routers serve
both hosts. Of course, each TRIGTRAN-capable access router will send
triggers to the "correspondent host" adjacent to the other access
router.
* TRIGTRAN is not a substitute for end-to-end mechanisms. TRIGTRAN
triggers must be advising the correspondent host on something that it
will figure out eventually without triggers.
* TRIGTRAN is per-transport-protocol. With two different transports
running over some link, if both transports have requested trigger
coverage, two separate triggers will be sent for a particular event.
* TRIGTRAN operations are not defined for an IP multicast address.
* Protocol notification message must contain enough information to
identify per-host-pair.
* Trigger notifications are injected when a specified event is detected
by the link-layer implementation on a TRIGTRAN-capable router for a
specified link.
* A correspondent node may ignore notifications even though it may have
requested trigger coverage for a TRIGTRAN Initiator.
* "Soft-state" for a per-host-pair should exist only at the adjacent
TRIGTRAN-capable router only.
* When TRIGTRAN notifications and end-to-end mechanisms are in conflict
the latter will take precedence over notifications.
Dawkins, Williams, Yegin Expires August 2003 [Page 6]
Internet-Draft TRIGTRAN Framework February 2003
* Triggers should be link-layer independent.
* Each TRIGTRAN notification will carry information for one event only.
The correspondent node should be able to determine by an appropriate
identifier field what event has taken place.
5. Trigger Events/notification
Presented in this section is an enumeration of the various triggers that
encompass the framework. Motivation and suggested responses are
provided for each trigger notification. This is a preliminary list of
notifications and their associated suggested responses.
These triggers were identified during our work in PILC as things
transports would WANT to know, but that are difficult to discover using
end-to-end signaling. For instance, "Connectivity Interrupted" can't be
signaled end-to-end, by definition.
Trigger: Connectivity Interrupted
Motivation:
When a link goes down TCP RTO exponential backoff occurs.
The sender will eventually "give up", assuming that
the receiving TCP (and perhaps the receiving host) will
not recover.
Suggested Response:
The correspondent transport may choose to perform normal RTO
processing for a longer period of time (in Solaris TCP, this would
be a longer tcp_ip_abort_interval).
Note that a TCP that continues to receive ACKs should ignore
this trigger.
Trigger: Connectivity Restored
Motivation:
When a link returns to working state, an other-end TCP
may have experienced RTO, and may be waiting to attempt
retransmission. Since TCP backs off exponentially (up to
64 seconds between retransmission attempts, in common
implementations), the receiver will be waiting unnecessarily.
Suggested Response:
Attempt single-packet probe immediately, if successful,
resume perform normal operation.
Dawkins, Williams, Yegin Expires August 2003 [Page 7]
Internet-Draft TRIGTRAN Framework February 2003
Note that this attempt should be made only once per
Connectivity Interrupted incident (clear when end-to-end ACKs
have been received during retransmission).
Trigger: Packets Discarded by subnetwork, not lost due to congestion
Motivation:
In some wireless handoff scenarios, a subnetwork may explicitly
discard packets at the "old" base station. In these cases, the
application will either Fast Retransmit/Fast Recover or RTO/Slow
Start (depending on whether additional ACKs are received for packets
delivered by the new base station). These losses will reduce the
congestion window, although they are not caused by congestion.
Suggested Response:
Retransmit without performing congestion avoidance. Note that this
attempt should be made only once per loss event (in the document
draft-allman-tcp-sack-13.txt, additional notifications would be
ignored until the "scoreboard" data structure is emptied).
6. Security assessment and considerations for the TRIGTRAN framework
TRIGTRAN mechanisms provide explicit notifications from access routers
to endpoint transport implementations that may be across the Internet.
The critical feature here is that the host receiving a TRIGTRAN trigger
is across an arbitrary network topology from the access router sending
the trigger, and the host receiving the trigger has no previous trust
relationship with the access router. The host receiving the trigger will
take some transport-level action (sending a packet, retransmitting a
packet, waiting for some period of time to transmit a packet, etc.).
The transports would "figure out an event" eventually, given enough
time. TRIGTRAN is intended to provide network-based hints that clue the
transport in more quickly (where "quickly" is measured in RTTs, not in
milliseconds). Since "link down" will probably be one of the triggers,
end-to-end mechanisms cannot be used to send explicit notifications
(since one of the ends isn't accessible).
A security assessment for TRIGTRAN amounts to evaluating what impact a
forged trigger can have on a host that uses the hints to deal with the
respective event. For example, we don't want TRIGTRAN to provide a
mechanism for denial of service attacks, etc. (this should be obvious,
but let's make it explicit).
Dawkins, Williams, Yegin Expires August 2003 [Page 8]
Internet-Draft TRIGTRAN Framework February 2003
TRIGTRAN triggers are advisory in nature - they do not replace
transport-level mechanisms (in the case of TCP, the receiver's ACK
stream). If a correspondent host gets a forged "Connectivity
Interrupted" trigger, but continues to receive ACKs from the actually-
reachable TRIGTRAN Initiator, the reasonable action is to ignore the
trigger, not the ACKs. If a correspondent host gets a forged
"Connectivity Restored" trigger, but does not receive ACKs from the
actually-unreachable receiver, the transport would take its normal
action for an unresponsive receiver (in the case of TCP, this would be
RTO, retransmission, and slow start). The correspondent host can use
existing transport-level mechanisms to determine the validity of the
trigger. Because TRIGTRAN triggers are advisory the correspondent host
isn't required to act as if the events are real. Thus, we don't think a
security association is required between the TRIGTRAN router and the
correspondent host receiving triggers. If one is present, fine, but it's
not required.
The alternative, requiring the host to establish trust relationships
with arbitrary routers in other administrative domains in order to
receive triggers, seems to be overkill in this situation. If TRIGTRAN
triggers overrode end-to-end mechanisms, a trust relationship would
clearly be required.
We note that, in the absence of trust relationships between TRIGTRAN
Initiators and TRIGTRAN routers, it's possible for forged packets to
fill up the TRIGTRAN router's "soft state" notification table. If we are
true to our self-imposed restriction that all triggers would be advisory
in nature, a denial-of-service attack would have the effect of disabling
TRIGTRAN, and normal end-to-end mechanisms would prevail - as they do
today.
Our self-imposed limit to access routers for our initial work may help
here - the access router would have some ability to "ingress-filter"
trigger coverage requests, as edge routers filter on IP address prefixes
today.
7. Why TRIGTRAN is Not Doomed
At the IETF 55 TRIGTRAN BoF, Sally Floyd presented a number of
questions for TRIGTRAN. One of the most relevant was "ICMP
Source Quench failed. P-MTU Discovery failed. Why will TRIGTRAN
be different?"
This question needs to be answered. Our crack at an answer
follows.
7.1 Why TRIGTRAN Is Not Doomed (Source Quench)
RFC 792 describes the Internet Control Management Protocol
(ICMP). ICMP includes a message type called "Source Quench"
(Type 4). Source Quench was intended to provide "back pressure"
Dawkins, Williams, Yegin Expires August 2003 [Page 9]
Internet-Draft TRIGTRAN Framework February 2003
when a gateway discards an incoming IP datagram because no
buffers are available. The message is sent to the Source IP
Address carried in the discarded IP datagram. Conceptually, a
host receiving an ICMP Source Quench message would slow down
its sending rate until it stopped receiving ICMP Source Quench
messages, and then gradually increase its sending rate.
The original specification did not provide quantitative
guidance on HOW MUCH to slow down. RFC 1016 proposed a formula
Source Quench Induced Delay ("SQuID"), but this RFC was
published six years after RFC 792, and defined itself as a
"crazy idea". A better characterization might have been
"embryonic", reflecting an unsophisticated awareness of
congestion - TCP didn't include Slow Start/Congestion Avoidance
until a couple of years later.
The original specification allowed gateways to generate an ICMP
Source Quench for every datagram dropped, but did not require
gateways to send them at all. RFC 1009 ("Requirements for
Internet Gateways") required gateways to include the capability
to send rate-limited ICMP Source Quench messages, but when it
was updated as RFC 1812 ("Requirements for IP Version 4
Routers"), this requirement was dropped in favor of deprecating
ICMP Source Quench ("Gateways SHOULD NOT"). The reasons given
for this about-face included:
- ICMP Source Quench affected only packets sent from the host
generating the "over the top" packet, so did not provide a fair
mechanism for hosts sharing overcommitted network paths, and
- ICMP Source Quench added (reverse-direction) packets to the
network during congestion events, and used router memory and
processing power to construct and send ICMP Source Quenches
during congestion events.
The overwhelming problem with ICMP Source Quench wasn't that it
required gateways to send a "trigger" to hosts - it had
problems with unfairness and inefficiency. Since the
specifications omitted critical details and didn't require this
functionality, hosts were forced to add end-to-end congestion
avoidance at the transport layer, anyway.
This experience isn't terrifically relevant to TRIGTRAN,
because standards-based recommendations have vacillated from
MAY to SHOULD NOT - hardly an overwhelming motivator to
deployment!
7.2 Why TRIGTRAN is Not Doomed (Path Maximum Transmission Unit
Discovery)
RFC 791 ("Internet Protocol") allows IP packets of up to 65,535
octets, but subnetworks typically don't support frames with a
Dawkins, Williams, Yegin Expires August 2003 [Page 10]
Internet-Draft TRIGTRAN Framework February 2003
payload this large. A host can know the Maximum Transmission
Unit size for its local subnetwork, but can't be sure that a
path across multiple subnetworks will support a larger MTU
without IP fragmentation. RFC 1122 ("Requirements for Internet
Hosts -- Communication Layers") specified that IP
implementations "SHOULD" use an MTU of 576 or less to
communicate with hosts on a different network, unless the
implementation "knew" that the path supported larger MTUs.
RFC 1063 ("IP MTU Discovery Options") and its successor RFC
1191 ("Path MTU Discovery") described a mechanism to gain this
knowledge. An IP implementation wishing to use large MTUs sent
a packet of the desired size into the network with the "Don't
Fragment" bit set. If the packet encountered a subnetwork that
didn't support the desired MTU size, the gateway for that link
discarded the packet, and reported an ICMP ICMP Destination
Unreachable error with a code meaning "fragmentation needed and
DF set", (also described as "Datagram Too Big"), and an
indication of the bottleneck MTU size, stored in a previously-
unused ICMP header field. To avoid requiring a "flag day" for
P-MTU discovery, hosts were required to accept "Datagram Too
Big" errors that didn't include the bottleneck MTU size, and to
either fall back to 576 bytes or search with a new, lower P-MTU
"guess", thus accommodating gateways that hadn't been updated.
As P-MTU Discovery was deployed, another "discovery" happened.
As described in RFC 1435 ("IESG Advice from Experience with
Path MTU Discovery"), "some vendors have added to their routers
the ability to disable ICMP messages generated by the router".
The effect was that of a "black hole" - the router dropped the
"too big" datagram, but did not send any notification to the
sending host that this was happening. Further deployment
experience led to RFC 2923 ("TCP Problems with Path MTU
Discovery"), pointing out that "black holing" was still
happening, and that routers were configured this way for a
variety of reasons, including a misguided attempt to shut down
ICMP messages crossing firewalled administrative domains.
Procedures for hosts encountering "black holes" were described,
but guessing too high on a "black-holed" path still leads to
delays of several seconds as the host TCP implementation uses
timeouts to detect failure and "falls back" to 576 bytes.
The Internet experience with P-MTU Discovery is more relevant
to TRIGTRAN if TRIGTRAN considers ICMP messages as a trigger
signal mechanism, although the "black holing" problem is less
severe because TRIGTRAN triggers are advisory in nature. End-
to-end mechanisms will lead to the same result after some
delay.
The history of P-MTU Discovery is useful as a reminder that
TRIGTRAN triggers must traverse firewalls, no matter what
mechanism is defined to transport them.
Dawkins, Williams, Yegin Expires August 2003 [Page 11]
Internet-Draft TRIGTRAN Framework February 2003
8. Summary
While the draft is initially focusing on wireless links, other
link types (i.e. modems) are of importance and will be taken into
account. Moving forward with this work an eye on non-wireless links
will also be taken into account.
There are many ways to skin the cat and we are interested in hearing
about alternatives. The draft was put together as the output from the
IETF TRIGTRAN BOF in Atlanta 2002. This is a preliminary writeup whose
purpose is to facilitate the discussion of a second BOF in San Francisco
IETF in March 2003. The preliminary thinking in this draft would
serve to create additional discussion highlighting issues and hopefully
asking the right questions.
9. Acknowledgements
Thanks to Ted Hardie for coming up with a good abstract and other
comments on the draft. Thanks to Sally Floyd for numerous
comments and questions raised at the IETF Atlanta BOF on TRIGTRAN
that structured much of the text for this draft as well as her
insightful review of this draft. Thanks to Mark Allman, Aaron
Falk, and John Wroclawski for their inputs on this draft and
contributions on the mailing list on this subject matter. Also,
thanks to those who have contributed to the IETF Atlanta BOF
discussion and comments on the TRIGTRAN mailing list. Special
thanks to Allison Mankin for her vision and leadership on dealing
with this problem space.
10. References
[BAR-BOF] Notes from L2 Triggers meeting (PILC mailing
list posting), Aaron Falk and Carl E. Williams, April
2002, available from
http://pilc.grc.nasa.gov/list/archive/1837.html.
Several of the following drafts describe lower-latency
triggers intended for Mobile IP fast handoff. TRIGTRAN
reuses a number of concepts from this work.
[CORSON] A Triggered Interface (work in progress), Scott
Corson, May 2002, draft-corson-triggered-00.txt
[WILLIAMS]Problem Statement for Link-layer Triggers work
(work in progress), Carl Williams, Alper E. Yegin, and
James Kempf, June 2002, draft-williams-l2-probstmt-00.txt
[YEGIN] Link-layer Triggers Protocol (work in progress),
Alper Yegin, June 2002, draft-yegin-l2-triggers-00.txt
Dawkins, Williams, Yegin Expires August 2003 [Page 12]
Internet-Draft TRIGTRAN Framework February 2003
[GURI] Layer-2 API for Paging (expired work in
progress), Sridhar Gurivireddy, Behcet Sarikaya, Vinod
Choyi, and Xiafeng Xu, October 2001,
draft-guri-seamoby-paging-triggers-00.txt
[MANYFOLKS] Supporting Optimized Handover for IP Mobility :
Requirements for Underlying Systems (work in progress),
Alper Yegin (editor), June 2002,
draft-manyfolks-l2-mobilereq-02.txt
[PILC] Performance Implications of Link Characteristics
IETF Working Group
http://www.ietf.org/html.charters/pilc-charter.html
[RFC896] Congestion Control in IP/TCP Internetworks,
IETF RFC 896, January 1984, John Nagle.
[RFC792] Internet Control Message Protocol, IETF RFC 792,
September 1981, Jon Postel.
[RFC1016] Something a Host Could do with Source Quench: The
Source Quench Introduced Delay (SQuID), IETF RFC 1016,
July 1987, Jon Postel.
[RFC1009] Requirements for Internet Gateways,
IETF RFC 1009, R.Braden and Jon Postel, June 1987.
[RFC1812] Requirements for IP version 4 Routers,
IETF RFC 1812, Editor: Fred Baker, 1995.
[RFC791] Internet Protocol, IETF RFC 791, September 1981,
Editor: Jon Postel.
[RFC1122] Requirements for Internet Hosts ? Communications
Layers, IETF 1122, October 1989, Editor: R. Braden.
[RFC1063] IP MTU Discovery Options, IETF RFC 1063,
July 1988, J. Mongul, C. Kent, C. Partridge, K. McCloghrie.
[RFC1191] PATH MTU Discovery, IETF RFC 1191,
November 1990, J. Mogul, S. Deering.
[RFC1435] IESG Advice from Experience with Path
MTU Discovery, March 1993, FTP Software.
[RFC2923] TCP Problems with PATH MTU Discovery,
September 2000, K. Lahey.
Dawkins, Williams, Yegin Expires August 2003 [Page 13]
Internet-Draft TRIGTRAN Framework February 2003
11. Contact Information
Spencer Dawkins
Cyneta Networks
1201 North Bowser Road Phone: 1-469-385-2484
Suite 100
Richardson, Texas 75081
USA Email: sdawkins@cynetanetworks.com
Carl E. Williams
MCSR Labs
3790 El Camino Real
Palo Alto, CA 94306 Phone: 1-650-279-5903
USA Email: carlw@mcsr-labs.org
Alper E. Yegin
DoCoMo USA Labs
181 Metro Drive, Suite 300 Phone: +1 408 451 4743
San Jose, CA 95110 Fax: +1 408 451 1090
USA Email: alper@docomolabs-usa.com
Dawkins, Williams, Yegin Expires August 2003 [Page 14]