Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?]

"Anantha Ramaiah (ananth)" <> Wed, 21 November 2007 18:20 UTC

Return-path: <>
Received: from [] ( by with esmtp (Exim 4.43) id 1IuuC3-0002LB-0S; Wed, 21 Nov 2007 13:20:59 -0500
Received: from tcpm by with local (Exim 4.43) id 1IuuC1-0002L1-JQ for; Wed, 21 Nov 2007 13:20:57 -0500
Received: from [] ( by with esmtp (Exim 4.43) id 1IuuC1-0002Kt-7K for; Wed, 21 Nov 2007 13:20:57 -0500
Received: from ([]) by with esmtp (Exim 4.43) id 1IuuC0-0002tm-LS for; Wed, 21 Nov 2007 13:20:57 -0500
Received: from ([]) by with ESMTP; 21 Nov 2007 10:20:57 -0800
Received: from ( []) by (8.12.11/8.12.11) with ESMTP id lALIKj9t032216 for <>; Wed, 21 Nov 2007 10:20:45 -0800
Received: from ( []) by (8.12.10/8.12.6) with ESMTP id lALIKfuu023194 for <>; Wed, 21 Nov 2007 18:20:45 GMT
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Nov 2007 10:20:38 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?]
Date: Wed, 21 Nov 2007 10:12:44 -0800
Message-ID: <>
In-Reply-To: <>
Thread-Topic: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?]
Thread-Index: AcgsAhInOuk3ynh1QD6d/9hO9momLwABmDVA
From: "Anantha Ramaiah (ananth)" <>
X-OriginalArrivalTime: 21 Nov 2007 18:20:38.0710 (UTC) FILETIME=[37AA7560:01C82C6B]
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3524; t=1195669245; x=1196533245; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;;; z=From:=20=22Anantha=20Ramaiah=20(ananth)=22=20<> |Subject:=20Summary=20of=20responses=20so=20far=20and=20proposal=20moving =20forward=20=20[Was=20Re=3A=20[tcpm]=20Is=20this=20a=20problem?] |Sender:=20; bh=RWAGOvS3cVppRN42w6H3iyWWEMVnLhW/54PcpXuTH4o=; b=KOeNkOMOHylwIMjdrMx8ULlnXs1rnygc3oEXOk2uODltpbj0imJc8R675b0WJLoFkCLvOp2a n7pzSWz+SHqbW1/YhkpI1cyHUgfmK146sbNdNLoaZhjfNoAyrduf+C0R;
Authentication-Results: sj-dkim-4;; dkim=pass ( sig from verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

I managed to read all the responses so far on this thread. At the time
of writing this email, there have been 54 email exchanges (includes the
authors' responses) around 9 people have responded so far not counting
the private email exchanges. In order to prevent rat-holing this further
I would like to step back a little and pose the following questions :-

A) Do we agree that it is a problem ? [the title of the thread]

   Most people seem to agree on this.

B) Do we think this is an issue to be dealt at the transport layer?

   Here there seems to be mixed reaction. Granted that there may be many
people feeling that this is an application issue and not a transport

Now expanding on B), 

Now the draft is talking about 2 things actually 3 things.

1) It is asking to correct/clarify the verbiage of RFC 1122. ie., RFC
1122 tells the connections MUST persist forever as long as ACK's are
received. Now, clearly as demonstrated in the draft, there needs to be
some ammount of robustness that can be built into the TCP layer, which
can allow the connection to be aborted after some stipulated time. Is
this considered a change in the standards? 

2) The draft also outlines a solution that can be helpful to deal when a
particular host is compromised with malicious intent. Agreed this may
not be the only solution possible, but it is one such. This purely falls
into "INFORMATIONAL" category. There is no TCP protocol change, it is
upto the implementation to chose an algorithm of choice. I think the
majority of the objection so far seems to be w.r.t point : "why TCP
layer should be responsible for resource allocation shemes"?  Again, I
think this is merely a suggestion and some implementations can chose to
implement it that way, there is no need to standardize this.

3) It also DOES mention about the application's role. Ie., in particular
it suggests the following :- 
   "Applications can assist TCP's role in solving this problem.  They
   register for an event notification when the TCP connection enters or
   exits persist condition.  They can use the notification mechanism to
   implement their own scheme of deciding which persist connections to
   clear.  They can also suggest timeout or retry values to TCP."

This only proves that the draft indeed does mention about application's
role in assisiting the problem. Again the above purely falls into
"informational" category.

So, in summary : Clearly 1) above calls for some change in existing TCP
behaviour. So even though it is not strictly "on the wire" change ( like
someone was pointing out) it is a change to the TCP standards. Now, why
can't TCP be made robust which would help to address situations like
this documented in the draft?  Is there a resistance to change the RFC
1122 verbiage even though it is helpful to do so? It is matter a
providing a new timer in TCP ( I think Ted menioned it in one his

2) and 3)  doesn't need any change to the standards. They illustrate the
problem and provide solutions and suggestions.

Given that there seems to be an agreement that this is a problem, the
way I look at is 1) above calls for a change in the standards. 2) and 3)
are more informational purpose only.

FWIW, the current "intended status" of the draft stands as

Thoughts/comments? Esp. there seems to to be some scope on re-wording
some sections of the draft to make the case more explicit, if that


tcpm mailing list