Subject: [Trigtran] TRIGTRAN Justification

From: "[email-masked]" <[email-masked]>
Date: Tue, 14 Jan 2003 23:29:47 -0500

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/trigtran

---

From: Kacheong Poon <[email-masked]>
Date: Tue, 14 Jan 2003 23:49:51 -0600 (CST)

Included message from "[email-masked]" <[email-masked]>:

>----
>----

It seems to me that the write up is trying to justify
some form of notification mechanism, not necessarily
trigger.  I am in favor of some form of such mechanism.
But I think trigger is the wrong mechanism to investigate.
We have learnt from ICMP that trigger is problematic.
This point was raised in the IETF BOF, as mentioned in the
minutes.  I don't see any discussion suggesting the
experience we learnt is wrong.

Using the example in the write up.  Assuming a simple
802.11b link, the end host's IP stack is well aware of
the link up and down (association/reassociation with
different access points) events.  If we use some form
of end2end notification mechanism, kick start(?), in
the transport level, the same benefits described
in the write up can be achieved.  What is the advantage
of using trigger, a form of notification outside of
any transport level connection context?  If TRIGTRAN is
only going to focus on access link, it seems that other
end2end notification mechanism will have the same effect,
but without those problems with trigger.

So again, what is the problem with notification mechanism
similar to ECN?  This kind of mechanism will also work
with non access link, as demostrated with ECN.  Why not
follow the same idea?

							K. Poon.

---

From: [email-masked]
Date: Wed, 15 Jan 2003 13:41:22 -0600

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 [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, January 14, 2003 10:30 PM
> To: [email-masked]
> Subject: [Trigtran] TRIGTRAN Justification
> 
> 
> 
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 15 Jan 2003 13:57:05 -0600

Hi, Yogesh,

I'm totally confused as to how I ended up with a trialing "/" in my previous posting to the list - the link you're looking for is http://www.ietf.org/proceedings/02nov/slides/trigtran-5.pdf, I believe.

Sorry for my misstep!

Spencer

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, January 15, 2003 1:41 PM
> To: [email-masked]; Spencer Dawkins; [email-masked]
> Subject: RE: [Trigtran] TRIGTRAN Justification
> 
> 
> Hi,
>

---

From: Kacheong Poon <[email-masked]>
Date: Wed, 15 Jan 2003 18:14:44 -0600 (CST)

>protocols such as RTP over UDP, or raw UDP with TFRC, also make use of

I think this is one important question to answer.  I
don't know if this is one of the original motivations of
trigger to be an "universal notification mechanism" for
all transports.  I agree that it would be nice, but it
is probably wrong to do it.  We know that there is not
an "universal transport" and it is probably wrong to have
one.  The same reasons apply to transport notification
mechanism.

>TRIGTRAN for UDP applications...

The above is a good reason not to have trigger as a
notification mechanism.  The mechanism has to be aware of
end2end transport context to be effective.  This means that
it is probably good to do it end2end.

>presence of all the other IETF protocols.

Another point against trigger.  An end2end notification
mechanism does not have this problem, or can get around it
easily, for example ECN.

>the network is not flooded with TRIGTRAN messages..., etc.

Yet another point not to use trigger as a notification
mechanism.

I believe when people continue to look into trigger as a
transport notification, more and more problem will be
found, as we have learnt from ICMP.  I suggest we should
look at other forms of transport notification or how to
put notification into existing transports as the starting
point.

							K. Poon.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 16 Jan 2003 19:31:18 -0600

Hi, Kacheong,

Thank you for the helpful feedback. I have some responses inline, and am interested in other opinions, too.

Spencer

> From: Kacheong Poon [mailto:[email-masked]]
> Sent: Tuesday, January 14, 2003 11:50 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Trigtran] TRIGTRAN Justification
> 

Again - not as a direct reply to your e-mail - Carl and I have been working on a writeup about our ICMP experience. I'll post it to the mailing list in a few minutes.

> but without those problems with trigger.

I'm certainly not against end-to-end notifications!

The usage scenarios I'm looking at (speaking only for myself) include situations where (1) a very interesting trigger/notification is that one host isn't reachable, so it can't tell the other host about THIS happening, and (2) measured RTTs are seconds long, with pretty wide variances, so RTOs tend to be over 8 seconds, so I'd prefer not to rely on RTO as a notification.

Again, I'm sending a pointer to some excellent discussions at TSVWG Adelaide to the mailing list (not just in response to this e-mail - Allison has been referring to it in our discussions, and I finally chased it down tonight).

> with non access link, as demostrated with ECN.  Why not

You're raising (for the first time) an interesting question here - I know I've been assuming that it would be easier to create a new mechanism than to modify existing transports. Does anyone else have opinions about this? Is it realistic to add states to TCP that reflect new kinds of notifications, for instance?

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 16 Jan 2003 19:31:27 -0600

Hi, Yogesh,

I have some notes (inline) - thanks for your helpful thoughts...

Spencer

> protocols such as RTP over UDP, or raw UDP with TFRC, also make use of

As one data point - I've been asked by one streaming media vendor (hint, hint) for help with mobiles that can't sent RTCP messages when they're not reachable (there's nothing that tells the RTP sender that this is happening).

I can't tell you that TRIGTRAN needs to take this on, or that this is a solvable problem. I'm just passing the request through to the mailing list.

> presence of all the other IETF protocols.

Yes, we definitely need to think about tunnels.

My immediate take is that, I don't know why TRIGTRAN shouldn't work, although a Transport IPSEC security gateway would have to relay the trigger (but it knows the relationship between the interior destination IP address and the tunnel, so this seems possible). But let's keep the question open, for now.

> present then it SHOULD be ignored by the transport)

You know... I'm hoping it doesn't work this way, because the problem we're dealing with, for TCP, is that there's only one defined inband signal (ACK clocking, or the lack thereof). But we're keeping explicit error notification on the "high-hanging fruit" list, so we certainly haven't demonstrated a need for lots of new signals yet.

> the network is not flooded with TRIGTRAN messages..., etc.

I think "what to do when you receive the SECOND TRIGTRAN message" has to be defined as part of any response mechanism. Good input.

---

From: Kacheong Poon <[email-masked]>
Date: Thu, 16 Jan 2003 21:29:22 -0600 (CST)

Included message from "Spencer Dawkins" <[email-masked]>:

>----
>The usage scenarios I'm looking at (speaking only for myself) include
>situations where (1) a very interesting trigger/notification is that one host
>isn't reachable, so it can't tell the other host about THIS happening, and (2)

As I mentioned in the previous mail, what benefit does this trigger really
have?  What is the advantage over the end2end notification I suggsted?
I guess they have to be made very clearly.  Just that one end cannot
be reached does not really justify that a trigger is needed.

>measured RTTs are seconds long, with pretty wide variances, so RTOs tend to be
>over 8 seconds, so I'd prefer not to rely on RTO as a notification.

Could you elaborate on this point?  The scenario mentioned in the
justification was to avoid the other end to timeout prematurely.  I
don't understand why an 8 seconds RTO matters here.  Or are you
suggesting that the trigger actually tells the other side that one
end has gone away forever?  And because RTO is 8 seconds, the trigger
can speed this up so that the other side will forget about the
connection quicker?  This does not sound right.  Please elaborate.

>You're raising (for the first time) an interesting question here - I know
>I've been assuming that it would be easier to create a new mechanism than to
>modify existing transports. Does anyone else have opinions about this? Is it
>realistic to add states to TCP that reflect new kinds of notifications, for
>instance?

It really depends on what the new mechanism is.  I don't think trigger
is a good mechanism at all.  If the trigger is advisory only and we know
that any machine can forge one, I am sure that all implementations will
simply ignore any trigger.  If this is the case, what is the point of
trigger?

I believe the basic criterion for a new mechanism is that it must
work more effectively than any solution by amending existing technology.
If people have not even looked at how existing technology can be
changed potentially, I'm afraid that thinking of a new mechanism at
this point is not a wise thing to do.

							K. Poon.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 17 Jan 2003 11:49:20 -0600

Hi, Kacheong,

Thanks for your thoughts and questions.

For all - note that we're still writing the justification document. There ARE
still questions that need to be figured out! All comments welcomed...

My notes inline...

Spencer

> Sent: Thursday, January 16, 2003 9:29 PM
> To: Spencer Dawkins; [email-masked]

What I'm thinking about here is giving a TCP sender a clue that what they're 
seeing with RTT time variation has little to do with congestion. I note that 
(per RFC 2988) we don't include retransmitted packets in RTO calculations 
(Karn's algorithms) - I'm wondering about, but not proposing, similar treatment 
when the TCP sender is notified of intermittant connectivity. 

> connection quicker?  This does not sound right.  Please elaborate.

This is the "backed off RTO timer" issue - after only one or two RTO backoffs, 
I'm looking at a really long interval after a host becomes reachable, before 
the other-end TCP sender reattempts the transmission. TCP Kickstart was a
proposal to solve this problem with end-to-end notifications.

> simply ignore any trigger.  If this is the case, what is the point of

You may be right. I hope not.

This is an Allison/Scott question, but my impression is that
there's a LOT of entrophy for TCP changes (to the point of proposed 
changes that orbit in Experimental RFC-land before they go to 
standards track).

> this point is not a wise thing to do.

I agree that this is a good thing to think about. I think it's also
good to think about the amount of entropy involved in making changes
to TCP to accomplish these tasks. I can't tell you what the right
trade-off is (that would be a BOF/WG concensus question, right?).

---

From: Kacheong Poon <[email-masked]>
Date: Fri, 17 Jan 2003 13:10:57 -0600 (CST)

>when the TCP sender is notified of intermittant connectivity. 

This is the reaction to such event you are referring to.  What I
was trying to find out is whether trigger is a good mechanism
to do such signalling.  IMHO, it is not.  An end2end mechanism
is preferred, and I think it can achieve the same thing.  We
can investigate what an appropriate reaction to such event is
later.

>proposal to solve this problem with end-to-end notifications.

Yup, there can be end2end mechanisms for such event.  Trigger is
not really needed.

>changes that orbit in Experimental RFC-land before they go to 

To me, Experimental does not necessarily mean that it won't be
deployed in real world.  It depends on what that change is.
NewReno is widely deployed (there is a commercial implementation
even before RFC 2582 was published) and it is still Experimental.
If I remember correctly, SACK (RFC 2018) was not published as
a Proposed when it first came out (I may be wrong here), and
there were commercial implementations.  Before ECN (RFC 2481)
became a Proposed (RFC 3168), there was implementation deployed.
And when it was published, there was commercial implementation.
I won't consider such change pace as slow.

>trade-off is (that would be a BOF/WG concensus question, right?).

I guess another point to look at is where that change is mostly
needed.  Please correct me if I am wrong, it seems to me that so
far the majority of voice for such notification comes from
wireless communication.  And I guess those devices are only started
to appear, which means that there will be continuous development.
The inertia not to change in this sector is not there.  As a matter
of fact, it is better to have an end2end change than a change which
requires cooperation of routers.  Routers are deployed already,
while those devices which make use of the change are not there yet.
Which is harder to change?

In summary, if the change is well thought of and the benefits of
such a change is great, it will be deployed.  Both are necessary
conditions, I think.

							K. Poon.

---

From: Kacheong Poon <[email-masked]>
Date: Fri, 17 Jan 2003 13:27:10 -0600 (CST)

Included message from "Spencer Dawkins" <[email-masked]>:

>My immediate take is that, I don't know why TRIGTRAN shouldn't work, although
>a Transport IPSEC security gateway would have to relay the trigger (but it
>knows the relationship between the interior destination IP address and the
>tunnel, so this seems possible). But let's keep the question open, for now.
>----

My understanding of what Yogesh said is a little bit different.
Consider the most common case scenario in today's Internet.  People
use IPsec to setup VPN tunnels between their machines and corporate
gateways.  In the scenario considered by TRIGTRAN, one end point of
the tunnel is actually behind the "problematic link."  The router
on the other side of the "problematic link" has no idea what is
going on.

							K. Poon.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 17 Jan 2003 13:30:52 -0600

Hi, Kacheong,

What I'm getting from your e-mails is that we're 
missing a possible path forward.

I've been looking at only two choices:

- implicit end-to-end signaling, and 
- explicit triggers

If I'm getting your point (please let me know if not), 
you're thinking of a third choice,

- explicit end-to-end signaling

Would you see this as part of TCP, 
or a completely different mechanism?

I don't own stock in triggers, you know... 
We COULD change the name of the mailing list!

Spencer

> Sent: Friday, January 17, 2003 1:11 PM

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 17 Jan 2003 13:58:12 -0600

Hi, Kacheong,

We're looking at two different topologies here.

I agree that your scenario is common on today's Internet.

On most of the deployed WIRELESS networks I've seen, 
almost all corporate IPSEC VPN tunnels terminate at 
the gateway into the wireless network (no IPSEC within 
the wireless network). In this case, TRIGTRAN-capable 
access router wouldn't be affected by IPSEC VPN tunnels.

Spencer

> Sent: Friday, January 17, 2003 1:27 PM

---

From: Kacheong Poon <[email-masked]>
Date: Fri, 17 Jan 2003 15:12:43 -0600 (CST)

>or a completely different mechanism?

Yes, I think it is another choice that should be evaluated
before deciding which notification mechanism is the best
one to spend effort on.

							K. Poon.

---

From: Kacheong Poon <[email-masked]>
Date: Fri, 17 Jan 2003 15:19:18 -0600 (CST)

>access router wouldn't be affected by IPSEC VPN tunnels.

I see.  I guess the point to note is that trigger will
not work in all kind of network topology.  I believe an
end2end mechanism will.

							K. Poon.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 17 Jan 2003 15:24:15 -0600

OK, I think we've talked this through. My suggestion is that 
the next couple of weeks, we focus on what additional things 
a transport would want to know, that transports don't get told
explicitly today.

Spencer

> Sent: Friday, January 17, 2003 3:13 PM