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

Ted Faber <faber@ISI.EDU> Thu, 22 November 2007 00:38 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv054-0002l5-Un; Wed, 21 Nov 2007 19:38:10 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Iv053-0002bD-Jr for tcpm-confirm+ok@megatron.ietf.org; Wed, 21 Nov 2007 19:38:09 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iv053-0002Zm-9v for tcpm@ietf.org; Wed, 21 Nov 2007 19:38:09 -0500
Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iv04z-0006LC-E6 for tcpm@ietf.org; Wed, 21 Nov 2007 19:38:09 -0500
Received: from hut.isi.edu (hut.isi.edu [128.9.168.160]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id lAM0anq6000893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 21 Nov 2007 16:36:49 -0800 (PST)
Received: (from faber@localhost) by hut.isi.edu (8.14.2/8.14.2/Submit) id lAM0an8C022876; Wed, 21 Nov 2007 16:36:49 -0800 (PST) (envelope-from faber)
Date: Wed, 21 Nov 2007 16:36:48 -0800
From: Ted Faber <faber@ISI.EDU>
To: Mahesh Jethanandani <mahesh@cisco.com>
Subject: Re: Summary of responses so far and proposal moving forward [Was Re: [tcpm] Is this a problem?]
Message-ID: <20071122003648.GN13024@hut.isi.edu>
References: <20071121192901.GF13024@hut.isi.edu> <0C53DCFB700D144284A584F54711EC58044CE020@xmb-sjc-21c.amer.cisco.com> <20071121213610.GH13024@hut.isi.edu> <4744AE06.1090808@cisco.com> <20071121224514.GJ13024@hut.isi.edu>
Mime-Version: 1.0
In-Reply-To: <20071121224514.GJ13024@hut.isi.edu>
User-Agent: Mutt/1.4.2.3i
X-url: http://www.isi.edu/~faber
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: faber@hut.isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 00e94c813bef7832af255170dca19e36
Cc: tcpm@ietf.org, "Anantha Ramaiah (ananth)" <ananth@cisco.com>
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0933977406=="
Errors-To: tcpm-bounces@ietf.org

As an individual.

On Wed, Nov 21, 2007 at 02:45:14PM -0800, Ted Faber wrote:
> On Wed, Nov 21, 2007 at 02:15:34PM -0800, Mahesh Jethanandani wrote:
> > I saw this e-mail just after I had hit the send button for my last e-mail.
> > 
> > Ted Faber wrote:
> > >I (personally) don't see the point of publishing an RFC that describes
> > >a technique that a conformant TCP cannot implement.
> > >  
> > I do not see any reason why the proposed solution cannot be implemented. 
> > Are you suggesting that because we cannot implement it is why it should 
> > not be implemented?
> 
> The conformant TCP cannot implement the fix because it would violate
> 1122 and then no longer be a conformant TCP. 
> 
> I understand you can write the code.

This is actually pretty unclear of me.  I seem to be arguing both that
the mechanism in the draft violates 1122 and doesn't.  Let me be more
careful:

A system that requires an IETF standard interface to the TCP stack that
specifies a timeout to abort connections holding a zero window longer
than that timeout violates 1122, IMHO.  Because the interface is to TCP
that implies that TCP would do the abort and this action (TCP doing the
abort) would violate 1122.  You can't describe the system as an
interface to TCP and not have it violate 1122.

A system that adds an OS interface to do the same thing would not
violate 1122.  The interface needn't pass through the IETF, which
doesn't standardize application <-> OS interfaces.  The OS aborting a
TCP connection violates no RFC I can think of.  No IETF standards action
required here, though if you wanted to make it part of a standard OS
interface, the interface would need to be reviewed by the relevant body.

I realize that there's an odd something going on here in that the same
action, described slightly differently, does or doesn't require a
standards change.  The difference is that the first choice - creating a
new TCP interface - has ramifications (admittedly small ones) to other
TCP implementations.  Ramifications to other TCP interfaces means the
changes need to conform to other standards.

Given that you can implement the mitigation either with or without
changing standards, why change them?

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm