Subject: Re: [Trigtran] TCP & Link Outages

From: Sally Floyd <[email-masked]>
Date: Mon, 09 Dec 2002 11:54:30 -0800

Reiner -

[Apologies for the late reply...]

...
>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.
...
>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."

Thanks, I just reread that section of RFC1122.  

It leaves open the question of whether explicit triggers would be
useful to advise the transport and/or application to set R2 (the
number of retransmissions of the same segment before the TCP sender
closes the connection) to a greater value, it seems to me.  

Without explicit triggers, the TCP sender can't tell whether the N
retransmissions of the same segment are due to a (hopefully temporary)
link outage, or due to heavy and persistent congestion somewhere
along the path.  The appropriate response to the first (the link
outage) might be for the TCP sender to have a higher value of R2,
while the appropriate response to the second (the heavy, persistent
congestion) might be a smaller value for R2 (because the user might
rather just give up than be strung-along with a TCP connection that
is never going to make any significant progress).  If the transport
and app would not find the LINK DOWN trigger useful in setting R2,
then the case for an explicit LINK DOWN trigger would be weaker, 
it seems to me.

- Sally

(Even in the case of the possible link outage, there could be
congestion on the path to get to the failed link, and the retransmitted
packets could be wasting scarce bandwidth.  But the retransmit timer
is pretty far backed-off at this point, and the explicit LINK UP
trigger, or the implicit trigger of the link retransmitting one of
the saved packets, would be used to notify the transport that the
link was back up, I presume...)

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

---

From: Sally Floyd <[email-masked]>
Date: Mon, 09 Dec 2002 12:46:47 -0800

Armando -

>> 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.  
...
>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.

Well, on thinking it over, the CWV (Congestion Window Validation)
mechanism is probably not relevant to this scenario in any case.
With CWV, the sender reduces the congestion window roughly once per
RTO, for a quiescent connection.  And after the quiescent period,
the TCP sender gets to slow-start back up to 3/4's of its old cwnd
value.  But a link outage with dropped packets is not the same as
a quiescent connection, and CWV wouldn't be invoked at all in this
case - the retransmit timer would expire first.  (CWV is really
targetted for connections with quiescent periods, and not targetted
for connections with long outages and retransmit timers expiring
for "dropped" packets.)

I also agree that the current congestion control mechanisms are far
from optimal in the case of a link outage. The current mechanisms,
after many failed retransmissions of the same packet, would be to
slow-start with a very small value for ssthresh.  If one knew that
the outage was a Link Down/UP event with the same link, then one
might want to slow-start with ssthresh set to cwnd/2, for cwnd the
value before the first loss of this packet.  

And if one knew that the outage was a Link Down/UP event to a
completely new link, and that link had been the bottleneck link for
the path, then one might want to slowstart using the default
(infinite) value for ssthresh for an initial slow-start.  But one
would have to look at the benefits of using a large value for
ssthresh (being able to take prompt advantage of newly-available
bandwidth) vs the costs (all of the flows that had been sharing
that link would all get Link UP notifications, at the same time,
and all slow-start with a large value of ssthresh, resulting in
unnecessarily large packet drop rates, retransmit timeouts, and a
short period of worse performance for everyone).

So I agree that an explicit Link UP trigger might be useful to the
TCP connection in deciding how to set ssthresh, but it is not obvious
to me what that value of ssthresh should be.

- Sally