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

Joe Touch <touch@ISI.EDU> Thu, 29 November 2007 18:04 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 1Ixnki-000821-IS; Thu, 29 Nov 2007 13:04:44 -0500
Received: from tcpm by megatron.ietf.org with local (Exim 4.43) id 1Ixnkh-00081M-Js for tcpm-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 13:04:43 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixnkh-00080w-3z for tcpm@ietf.org; Thu, 29 Nov 2007 13:04:43 -0500
Received: from vapor.isi.edu ([128.9.64.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixnkf-0001yS-ID for tcpm@ietf.org; Thu, 29 Nov 2007 13:04:43 -0500
Received: from [75.214.228.148] (148.sub-75-214-228.myvzw.com [75.214.228.148]) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id lATI4ISo005826; Thu, 29 Nov 2007 10:04:20 -0800 (PST)
Message-ID: <474EFF10.30401@isi.edu>
Date: Thu, 29 Nov 2007 10:04:00 -0800
From: Joe Touch <touch@ISI.EDU>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: David Borman <david.borman@windriver.com>
Subject: Re: Summary of responses so far and proposal moving forward[WasRe: [tcpm] Is this a problem?]
References: <389727.79747.qm@web31710.mail.mud.yahoo.com> <C186A11B-5858-4905-A4F9-E6DFC920B585@windriver.com>
In-Reply-To: <C186A11B-5858-4905-A4F9-E6DFC920B585@windriver.com>
X-Enigmail-Version: 0.95.5
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: TCP Maintenance and Minor Extensions WG <tcpm@ietf.org>, Mark Allman <mallman@icir.org>
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="===============0585575989=="
Errors-To: tcpm-bounces@ietf.org

FWIW, I agree with David's position here, and appreciate his raising the
distinction between implementation and specification.

Whether the app or the OS decides to terminate via the existing TCP API
ABORT call, that's an implementation issue.

I'd have opinions as to which is more correctly *implemented*, but
that's an implementation issue, not a protocol issue.

When resources are starved, I think good implementations inform the app
and let the app decide what to do. I don't think they have the OS run
down things it *thinks* aren't useful and free them. Again, however,
that's an implementation issue. I'll argue it, but it's not relevant to
the key question of whether we need a new protocol mechanism.

One final point:

David Borman wrote:
> 
> On Nov 28, 2007, at 7:32 PM, MURALI BASHYAM wrote:
...
>> A protocol is a contract between the sender and receiver here, and the
>> contract defines the wire
>> behaviour.
> 
> The TCP protocol is what is defined in RFC 793/1122, and any other RFCs
> that are applicable.  It is more than just the wire behavior.

This is as I have stated on multiple lists.

If there is a strong need for an RFC to explain concepts that are
ambiguous, this is MUCH more important than any other raised in this
entire thread.

Joe

_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm