[Trigtran] TRIGTRAN Justification

["[e-mail]" <[e-mail]>]

Below is a writeup on justification assessment
for TRIGTRAN.  Spencer and I are looking to
include the text in a framework/requirements
document.

Now seems a good time to discuss justification
with the recent emails.

Please provide comments/questions.

Thanks!
------------------------------------



Justification Assessment for TRIGTRAN
-------------------------------------


The rapidly growing Internet is being accessed
by an increasing wide range of devices over an
increasingly wide variety of links.  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

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 excessive amount
of time waiting for acknowledgements that do 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 "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 PILC working group.  With
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.

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 

            (taken from the Problem Statement I-D) 

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) transmission, but the
sender and receiver have been waiting when they could have 
been communicating.

TRIGTRAN can give the host receiving triggers hints that it
might reattempt the 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.

This write-up will be part of a framework/requirements
document that is being put together.  Please
provide any comments/issues on anything that we
are ignoring/overlooking with this justification.










--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .


_______________________________________________
Trigtran mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/trigtran