Re: [tcpm] draft-eggert-tcpm-historicize-00

Fernando Gont <fernando@gont.com.ar> Sat, 26 June 2010 07:18 UTC

Return-Path: <fernando.gont.netbook.win@gmail.com>
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 26CD53A689E for <tcpm@core3.amsl.com>; Sat, 26 Jun 2010 00:18:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.11
X-Spam-Level:
X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11]
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 hedJSB+rMbLo for <tcpm@core3.amsl.com>; Sat, 26 Jun 2010 00:18:03 -0700 (PDT)
Received: from mail-gx0-f194.google.com (mail-gx0-f194.google.com [209.85.161.194]) by core3.amsl.com (Postfix) with ESMTP id 134223A6862 for <tcpm@ietf.org>; Sat, 26 Jun 2010 00:18:02 -0700 (PDT)
Received: by gxk23 with SMTP id 23so27573gxk.1 for <tcpm@ietf.org>; Sat, 26 Jun 2010 00:18:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=JorOWmBDwWc2fGZsLAk8Dc8UTLxlCRY1KtkXUtbWWS0=; b=wufMZ4Wg2A6j5dDNVtLgFYbZYRbmfFkkBHSp/sGFBsf6mHD9r8EFQgy+Fvif0pmM04 uUqIx8ujLMjfcDKSSBAmlFivan+Gs5jpV8X7mYCeRDnexEGpas4kMRr+ytidMVh914nH YQV81/SeIRd31S3HSdzmCigdvmETRNW204FOU=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=dwAZpZHUohaIZ5ycMNQftlVipMgrYWJj6mCOlpnFbzLXyso8ke48wJYSyBKuINlQKs Ifnwx39r1u2Do67BdYSM4MJVMcjLU0jdPFM29/UQgcV5NOpb+bk6F3g8AuvCOGVt5RfY Gq4uZgEcIG3yUt+Q8GUH9m/IiSgHDKWCsdEQk=
Received: by 10.101.135.31 with SMTP id m31mr2206293ann.164.1277536689202; Sat, 26 Jun 2010 00:18:09 -0700 (PDT)
Received: from [190.48.244.65] ([190.48.244.65]) by mx.google.com with ESMTPS id b6sm12225310ani.1.2010.06.26.00.18.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 26 Jun 2010 00:18:03 -0700 (PDT)
Sender: Fernando Gont <fernando.gont.netbook.win@gmail.com>
Message-ID: <4C25A9A1.3040302@gont.com.ar>
Date: Sat, 26 Jun 2010 04:17:53 -0300
From: Fernando Gont <fernando@gont.com.ar>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Joe Touch <touch@isi.edu>
References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com><2262C708-DF9A-4DD9-9378-D84C5AF330AC@nokia.com><C304DB494AC0C04C87C6A6E2FF5603DB48105A5A82@NDJSSCC01.ndc.nasa.gov> <0C53DCFB700D144284A584F54711EC580A0CE306@xmb-sjc-21c.amer.cisco.com> <5FDC413D5FA246468C200652D63E627A0935F804@LDCMVEXC1-PRD.hq.netapp.com> <4C24F73F.9060402@isi.edu>
In-Reply-To: <4C24F73F.9060402@isi.edu>
X-Enigmail-Version: 0.96.0
OpenPGP: id=D076FFF1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: tcpm@ietf.org, "Anantha Ramaiah (ananth)" <ananth@cisco.com>, "Biswas, Anumita" <Anumita.Biswas@netapp.com>
Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00
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: <http://www.ietf.org/mail-archive/web/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>
X-List-Received-Date: Sat, 26 Jun 2010 07:18:04 -0000

Joe Touch wrote:

>> Our expirience has shown, that TCP often runs over links with much
>> higher error rates, than intended for the technology (ie. Design goal of
>> BER <= 1E-12 over Ethernet often has an actual BER >> 1E-12). If such
>> error-prone links are running at a high speed and with large segment
>> sizes (jumbo / giant frames), there exists the real problem that within
>> a short timeframe (weeks to months), TCP will deliver corrupted data, as
>> CRC-16 was not able to catch the error.
> 
> Just to confirm, is this a measured problem or a mathematical one? I.e., have
> you seen this actually occur (i.e., TCP with invalid CRC-16 but valid checksum)
> in the wild, in a lab, or have you never seen it but consider it important anyway?

IIRC, wasn't this sort of what the SIGCOMM (?) paper "when the checksum
and CRC disagree" (authored by J. Stone) was about?

Just my two cents,
-- 
Fernando Gont
e-mail: fernando@gont.com.ar || fgont@acm.org
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1