Subject: Link down, TCP connection down and session?

From: "Heqing Zhu" <[email-masked]>
Date: Wed, 16 May 2001 17:57:18 +0800

Hi,All:

For LDP, I have a question about session after link is down.
In fact, LDP defines some timer to check connection.
Suppose one link is down, What will happen about TCP connection?
If TCP connection is closed immediately, why we need the timer?
If anyone knows some discussion or classical article
Please give me some suggestion?

Thanks in advance

********************
Zhu Heqing
Beijing, China
********************

---

From: Haseeb Budhani <[email-masked]>
Date: Wed, 16 May 2001 03:15:18 -0500

> Please give me some suggestion?

'Sup Heqing,

I think you're referring to the reconnect timout for tcp connections.
RFC 3036 says that once the tcp connection is broken for any reason, or
if a tcp connection could not be created in the first place, a timer
should should be started before we try to establish a new tcp connection
to the same peer, and that the minimum value for this timout should be
no less than 15 seconds. Upon unsuccessful tcp negotiation, the timeout
should be be exponentially increased until it is no more than 2 minutes
or 120 seconds, but you should keep trying to set up the tcp connection
forever.

Hope I got it right. :)

--
Haseeb Budhani.

---

From: "Heqing Zhu" <[email-masked]>
Date: Wed, 16 May 2001 19:26:37 +0800

Maybe I didn't express it clearly.If LSR1 and LSR2 are connected directly,
and there are many LSPs between them, suppose the link fails, does TCP 
connection be closed immediately?
If this happens, why we still need some hold timer to check whether timout 
happen or not between two LSRs?

Anyway, thank you very much.

---

From: "Alexander Marhold" <[email-masked]>
Date: Wed, 16 May 2001 13:37:08 +0200

LDP session uses TCP
it uses loopbacks if available ( SA and DA )
if you have more physical or L3 connections between 2 nodes
---> then your LDP session stays even when one link goes down

with best regards

Alexander Marhold
Senior Consultant
PRO IN

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Heqing
Zhu
Sent: Wednesday, May 16, 2001 11:57 AM
To: [email-masked]
Subject: Link down, TCP connection down and session?

Hi,All:

Thanks in advance

********************
Zhu Heqing
Beijing, China
********************

---

From: Philip Chen <[email-masked]>
Date: Wed, 16 May 2001 09:46:47 -0400

Heqing,
  The problem is that TCP session is not closed immediately based on link
failure status. There is a reason why TCP session should not be teared down
simply because of a link failure. This is because TCP is designed with
robustness to transient network problems in mind (for example, a congestion
condition or temporary link failure). You certainly do not want to escalate
problems, for example such as an unstable link (flaping), everytime to above a
reliable transport layer (TCP). This way, applications using TCP can still get
some useful things done without need to worry about for example, a noise link
caused link flaping. TCP will handle reliable delivery of your data.
    Because of this, a broken TCP connection may not be detected for long
time, especially when application has no data to send. RFC1122 defines an
option for TCP implementation to detect such problem. This option is called
TCP keep-alive timer. Because of the concern that this timer may hurt TCP
robustness property, RFC1122 requires the value for this timer to be no less
than 2 hours by default. Most of the TCP implementation today include this
option, but the timer value is not tunable at per session basis. In other
words, this is a system wide parameter. However, you can turn on and off the
timer on per session basis (via socket setoption). Because of those
restrictions, this TCP keep-alive option is hardly used. Its primary use is
for some servers to cleanup junk connections for clients failed to close TCP
connection under certain circumstance, for example, your Windows system
crashed. Moreover, the TCP keep-alive feature cannot detect problems beyond
TCP layer, for example, your application hangs. For all of those reasons,
people favor to have a keep alive feature built into application, in this
case, LDP.

Hope this helps!

--Phil

---

From: Eric Gray <[email-masked]>
Date: Wed, 16 May 2001 10:34:46 -0400

Heqing Zhu,

    You need a hold timer, because loss of the link is only one thing
that could go wrong between two (otherwise amicable) LDP peers.
If an LDP instance gets locked up (it is in a loop, or has permanently
stepped out to lunch), the LSP related information from that peer is
of diminishing value over time.  Hence we use a hold timer.