Subject: [tcpm] New Draft for Lively TCP Connection Failure Notifications

From: <[email-masked]>
Date: Mon, 20 Jul 2015 09:13:05 +0530

Hi All,

We have proposed a new draft on Lively TCP Connection Failure Notifications. 

Name:           draft-aravind-tcpm-lively-failure-notifications
Revision:       00
Title:          Lively TCP Connection Failure Notifications
Document date:  2015-07-20
Group:          Individual Submission
Pages:          4
URL:            https://www.ietf.org/internet-drafts/draft-aravind-tcpm-lively-failure-notifications-00.txt
Status:         https://datatracker.ietf.org/doc/draft-aravind-tcpm-lively-failure-notifications/
Htmlized:       https://tools.ietf.org/html/draft-aravind-tcpm-lively-failure-notifications-00

Abstract:
   This document proposes a mechanism to provide lively notifications of
   TCP Connection Failures in Network.

We would love to hear your reviews and comments.

Cheers,
S. Aravind Prasad

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 20 Jul 2015 07:03:32 +0000

Hi,

Isn't this the reason for ICMP (Host) unreachable? 

Why terminate the TCP sessions - reading the text, it appears that the topology below assumes L3 forwarding devices; Shouldn't there be sufficient redundancy in the regular case to re-route around failed links?

Best regards,
  Richard

---

From: <[email-masked]>
Date: Tue, 21 Jul 2015 14:35:26 +0530

Dell - Internal Use - Confidential
Hi,

Thanks for the review comment.

Isn't this the reason for ICMP (Host) unreachable?
Actually, only for active TCP sessions, ICMP unreachable message would be received. In case of Inactive TCP sessions, there is no possibility of receiving ICMP message. Our proposal is more applicable to Inactive TCP sessions. Further, according to RFC 1122 Section 4.2.3.9 - TCP must not close the connection based on ICMP Destination unreachable (codes 0,1,5) messages. Hence, the core idea is to proactively track the loss of  network level connectivity to a subnet and inform the Server regarding the same.

 Why terminate the TCP sessions - reading the text, it appears that the topology below assumes L3 forwarding devices; Shouldn't there be sufficient redundancy in the regular case to re-route around failed links?
Actually, our proposed mechanism is more suitable at TORs which are the entry points to Network/Internet for Servers. In TORs, when the network connectivity to a particular subnet is lost (during network failures, routing protocols in network would converge and update the TOR's IP Table), it basically indicates loss of network connectivity to TCP sessions established at Server. Hence, in the case of inactive TCP sessions, the TOR can proactively initiate a TCP RST Message to Server informing it to tear down the corresponding session so that unnecessary wastage of kernel resources could be avoided.

Kindly let us know your comments.

Thanks,
S. Aravind Prasad

-----Original Message-----
From: Scheffenegger, Richard [mailto:[email-masked]]
Sent: Monday, July 20, 2015 12:34 PM
To: Sridharan, Aravind; [email-masked]
Cc: Venkatesan, Shathish
Subject: RE: New Draft for Lively TCP Connection Failure Notifications

Hi,

Best regards,
Richard

---

From: Joe Touch <[email-masked]>
Date: Tue, 21 Jul 2015 15:33:55 -0700

FWIW, we've been around this block a few times, including in TERNLI and
TRIGTRAN.

As has already been observed:

	- endpoints indicate failure using ICMP dest unreachable
	(some are soft errors, some hard)

	- routers indicate failure usings ICMP time/parameter
	(mostly soft because of the potential for alternate paths,
	as Richard noted)

You're basically proposing to:

	a) make an L2 switch issue TCP-level errors
	at best, it might issue ICMP errors, except that
	it can't because *it doesn't exist at the IP layer*

	b) issue forced hard errors for behaviors that RFC1122
`	already very clearly defines as soft (by issuing RSTs
	instead of ICMPs)

	c) spoof RSTs (see RFC4953), which won't work if
	the sources use TCP protection (RFC5961), IPsec (RFC4301),
	or TCP-AO (RFC5925)

You're making the system unpredictably fragile and ignoring the fact
that L2 might have alternate paths too (e.g., TRILL,
multi-spanning-tree, etc.).

Some other notes:

- HTTP had persistent connections before 1.1:
	V. Padmanabhan, J. Mogul, “Improving HTTP latency,”
	Proc. 2nd Int. World Wide Web Conf., Oct. 1994.

- inactive TCP connections may still be sending keepalives (this is
often needed to prevent orphan connections from consuming server state),
so they might still end up receiving ICMP errors

	and that's the right place to decide whether state needs to
	be cleaned up or not, frankly

- TOR entry points can make their own decisions
	
	if they run out of state and need to do a cleanup, they could
	simply delete state for paths that they consider stale. until
	TCP sends a new message, they should not be doing anything to
	that TCP connection. when the new message arrives, either
	by a keepalive or becoming active, it would generate the
	necessary ICMP

- You need not cite all the component RFCs associated with HTTP, and you
really do need to cite the RFCs I indicate above.

- And provide a convincing reason that this is both safe and necessary.

Joe

On 7/19/2015 8:43 PM, [email-masked] wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm
>

---

From: Yuchung Cheng <[email-masked]>
Date: Tue, 21 Jul 2015 22:22:19 -0700

I have similar concerns and find the proposal scary.

Linux implements RFC5961 so your device would have to keep per flow
state if the hosts/VMs are careful.