IETF Logo Mail Archive

Re: [tcpm] TCP-AO: Text for New_Key Process

Eric Rescorla <ekr@networkresonance.com> Tue, 03 February 2009 15:08 UTC

Return-Path: <tcpm-bounces@ietf.org>
X-Original-To: tcpm-archive@megatron.ietf.org
Delivered-To: ietfarch-tcpm-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C5603A682F; Tue, 3 Feb 2009 07:08:29 -0800 (PST)
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 820C63A682F for <tcpm@core3.amsl.com>; Tue, 3 Feb 2009 07:08:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.565
X-Spam-Level:
X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3PBge08Yqi5 for <tcpm@core3.amsl.com>; Tue, 3 Feb 2009 07:08:27 -0800 (PST)
Received: from romeo.rtfm.com (romeo.rtfm.com [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id 273EC3A6824 for <tcpm@ietf.org>; Tue, 3 Feb 2009 07:08:27 -0800 (PST)
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 8205A50822; Tue, 3 Feb 2009 07:24:49 -0800 (PST)
Date: Tue, 03 Feb 2009 07:24:49 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: Joe Touch <touch@ISI.EDU>
In-Reply-To: <4987EEF3.6040609@isi.edu>
References: <7.1.0.9.2.20081219010400.02bfd3d8@gmail.com> <496d9941.18038e0a.5558.ffffd3a6@mx.google.com> <497F7DDC.70309@isi.edu> <5E6CB562-0495-4D2B-924E-AB4650924151@nokia.com> <49876D92.6030701@juniper.net> <20090203041229.0584550823@romeo.rtfm.com> <4987EEF3.6040609@isi.edu>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <20090203152449.8205A50822@romeo.rtfm.com>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>, Allison Mankin <mankin@psg.com>, "skonduru@juniper.net" <skonduru@juniper.net>
Subject: Re: [tcpm] TCP-AO: Text for New_Key Process
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org

At Mon, 02 Feb 2009 23:14:59 -0800,
Joe Touch wrote:
> TCP doesn't *need* to send any packets. Whatever mechanism you design 
> needs to assume that.

If it doesn't need to send packets, then they don't need to be 
protected, in which case keys don't need to be changed,
so this lines up nicely.


> Also, "opportunistically" means that on some systems that packet would 
> go through, and on others it wouldn't - depending on when the key was in 
> place. So key placement would impact throughput (because TCP interprets 
> loss as congestion). While the impact could be reduced by using SACK, 
> etc., that's not a great place in the design space to play, IMO.

Once again, I'm having a hard time getting worked up over losing
one packet every 10-30 minutes.

-Ekr
_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www.ietf.org/mailman/listinfo/tcpm

v2.23.0 | Report a Bug | By Email