RE: [Trigtran] TRIGTRAN Justification

[[e-mail]]

Hi,

I have a couple of questions/comments based on these E-mails
(these issues might have already been addressed, but I was unable
to access the link that Spencer provided; can someone point me to
the right link?). Here are my questions/comments:

--  Is TRIGTRAN only considering TCP, or can other transport
protocols such as RTP over UDP, or raw UDP with TFRC, also make use of
it?

--  If it's supposed to help other protocols like RTP over UDP, or
UDP using TFRC for rate control, then we need to keep in mind that
unlike TCP, RTP does not have a protocol field in the IP
header. This means that given a stream of UDP packets, one cannot
*reliably* say if these packets belong to a RTP session, of if
they belong to some other protocol on top of UDP which just
happens to have the same format (It's good to be a little paranoid
while designing a new protocol, so don't bite off my head if you
think that the probability of such collisions are small) This also
means that TRINGTRAN routers cannot be stateful (i.e., one cannot
estimate RTT etc for a "flow"--whatever that means).

The framework should indicate such issues, or advise against using
TRIGTRAN for UDP applications...

--  If it's supposed to work only for TCP then it will be useful
to consider how it will work in the presence of IPSec tunnels. Of
course we can just say that it will not work with IPSec, but that
doesn't sound right (to me). Shouldn't IETF protocols work in the
presence of all the other IETF protocols.

--  Since TRIGTRAN is only advisory, it should not have signals
for which the transport layer does not have an in band counter
part. For example, handoff has no in band counterpart for TCP/UDP
and therefore such signals should not be present (but if they are
present then it SHOULD be ignored by the transport)

--  Also, for DoS attacks, TRIGTRANS should not only protect the
transport protocol, but it must protect itself, too. (This is
obvious, but it's probably useful to point it out explicitly.)
From the age-old example, one needs to consider how to handle IPv4
fragmentation; how to respond to multiple anomalies etc so that
the network is not flooded with TRIGTRAN messages..., etc.

Thanks in advance for your response.

Thanks
Best Regards
Yogesh

> -----Original Message-----
> From: ext [e-mail] [mailto:[e-mail]]
> Sent: Tuesday, January 14, 2003 10:30 PM
> To: [e-mail]
> Subject: [Trigtran] TRIGTRAN Justification
> 
> 
> 
> 
> 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.
> 
_______________________________________________
Trigtran mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/trigtran