Subject: Re: [Trigtran] TCP & Link Outages

From: Sally Floyd <[email-masked]>
Date: Mon, 02 Dec 2002 22:18:06 -0800

>Reiner is raising a topic Sally mentioned in her talk at TRIGTRAN
>last week - do we need explicit triggers, or would implicit triggers
>be sufficient? Retransmitting a packet when an interface becomes
>active looks like an implicit trigger to me.

My assumption is that transmitting one or more packets that arrived
while the link was down would be a good implicit trigger for TCP
in many cases, allowing the TCP connection to restart promptly after
a link outage.   This would be particularly effective when the saved
packet advances the cumulative acknowledgement field for the TCP
connection, OR when the TCP connection uses Limited Transmit.
It would be good to understand if there were also circumstances when
the implicit trigger would not work well.  

And clearly, a disadvantage of explicit triggers is that
explicit triggers won't work if they are blocked by firewalls.

One advantage of explicit triggers over implicit triggers could be
that the explicit trigger for the Link UP case requires less buffer
space and less bandwidth than the implicit trigger: the explicit
trigger requires only the packet header to be saved and transmitted,
while the implicit trigger requires that the entire packet be saved.
Given that both the implicit and the explicit trigger might no
longer be relevant when they are retransitted (e.g., because the
TCP connection retained connectivity via another path while the
link was down, or one of the ends of the connection has given up
and gone home), it might be useful to minimize the buffer space
used for saving the data packet during the link outage, or to
minimize the bandwidth used in transmitting the old packet after a
long link outage.  Another reason to avoid saving the entire data
packet is that the trigger might still be relevant, but the exact
data in the old packet might no longer be useful after the link outage.

Whether this potential advantage of explicit triggers in the LINK
UP case outweighs their myriad disadvantages is unclear to me.

I don't think that that an explicit Link UP trigger is needed to
invoke slow-start, to provide a smooth transition to a path that
might have entirely different characteristics in terms of bandwidth
availability.  It seems to me that the mechanisms of transport
protocols of responding to quiescent periods can work equally well
with implicit triggers as with explicit triggers, and are quite
appropriate in terms of starting up again after a quiescent period,
in a possibly-changed environment.  [I am not necessarily an unbiased
observer in this: RFC 2861 on TCP Congestion Window Validation is
one suggestion of what to do in this regard, though this is only
an Experimental RFC.]

For the Link DOWN case, there doesn't seem to be an implicit trigger,
so if a trigger is needed an explicit trigger is probably the only
possibility.  My understanding is that the explicit trigger would
be used to tell the TCP connection not to give up after N unsuccessful
retransmits, or to advise the app so that the app would take some
appropriate action. 

[Getting to email a little late...]

- Sally
http://www.icir.org/floyd/
_______________________________________________
Trigtran mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/trigtran

---

From: Reiner Ludwig <[email-masked]>
Date: Tue, 03 Dec 2002 10:37:28 +0100

>For the Link DOWN case, there doesn't seem to be an implicit trigger,

Hmmm, a TCP sender simply doesn't get any more ACKs. This could qualify as 
an implicit trigger. In fact, it triggers a timeout, or even multiple 
exponentially backed-off timeouts. Those retransmits are then some kind of 
explicit "probing triggers". Or ... ?

>retransmits,

There is a very relevant discussion in RFC1122 (4.2.3.5  TCP Connection 
Failures) on this matter. Especially the time/counter R2 ("SHOULD 
correspond to at least 100 seconds") is relevant.

>or to advise the app so that the app would take some
>appropriate action.

This is a good point. It is something that seems to be missing from many 
TCP implementations or the relevant socket API. Again two quotes from the 
mentioned section in RFC1122:
- "An application MUST be able to set the value for R2 for a particular 
connection.  "
- "TCP SHOULD inform the application of the delivery
                  problem (unless such information has been disabled by
                  the application; see Section 4.2.4.1), when R1 is
                  reached and before R2.  This will allow a remote login
                  (User Telnet) application program to inform the user,
                  for example."

///Reiner

---

From: "Armando L. Caro Jr." <[email-masked]>
Date: Tue, 3 Dec 2002 14:43:13 -0500 (EST)

> one suggestion of what to do in this regard, though this is only

You may be correct in the case that the change in available bandwidth is a
reduction. I am really not sure, but links may not be down long enough to
implictly trigger the CWV mechanism.

Also, if a new path provides more available bandwidth, then the CWV
mechanism doesn't help either. The transport continues to use a cached
ssthresh value from the previous path, which may mean the connection
changes to congestion avoidance mode prematurely. The performance
degradation is simply a function of the increase in available bandwidth.

~armando

0--                                                --0
| Armando L. Caro Jr.     |       [email-masked] |
| University of Delaware  |  www.cis.udel.edu/~acaro |
0--                                                --0