Re: [tcpm] Review of draft-zimmermann-tcpm-reordering-detection-02

Pasi Sarolahti <pasi.sarolahti@iki.fi> Wed, 25 February 2015 11:38 UTC

Return-Path: <pasi.sarolahti@iki.fi>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D8431A8741 for <tcpm@ietfa.amsl.com>; Wed, 25 Feb 2015 03:38:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level:
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SRt-rnZS_yRR for <tcpm@ietfa.amsl.com>; Wed, 25 Feb 2015 03:38:18 -0800 (PST)
Received: from kirsi1.inet.fi (mta-out1.inet.fi [62.71.2.203]) by ietfa.amsl.com (Postfix) with ESMTP id B4B3A1A0451 for <tcpm@ietf.org>; Wed, 25 Feb 2015 03:38:17 -0800 (PST)
Received: from t40700-la020.org.aalto.fi (130.233.145.129) by kirsi1.inet.fi (8.5.142.08) (authenticated as saropa-1) id 54E3C71100EFAC3A; Wed, 25 Feb 2015 13:38:15 +0200
Content-Type: multipart/alternative; boundary="Apple-Mail=_7F6E95AD-05DC-4B0D-AAC5-B614E953C6D0"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Pasi Sarolahti <pasi.sarolahti@iki.fi>
In-Reply-To: <5969_1424814894_54ECF32E_5969_791_1_EBB91F58-AF7A-4C67-9545-DDA67B919374@ifi.uio.no>
Date: Wed, 25 Feb 2015 13:38:13 +0200
Message-Id: <45CACDEC-0CF3-4F7C-80B6-A163144A86C4@iki.fi>
References: <5969_1424814894_54ECF32E_5969_791_1_EBB91F58-AF7A-4C67-9545-DDA67B919374@ifi.uio.no>
To: Michael Welzl <michawe@ifi.uio.no>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tcpm/vltr1QjfHuURSrD9d1GaN2Shq6g>
Cc: "tcpm@ietf.org Extensions" <tcpm@ietf.org>
Subject: Re: [tcpm] Review of draft-zimmermann-tcpm-reordering-detection-02
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 25 Feb 2015 11:38:20 -0000

Hi Michael,

On 24 Feb 2015, at 23:54, Michael Welzl <michawe@ifi.uio.no> wrote:

> I just read https://tools.ietf.org/html/draft-zimmermann-tcpm-reordering-detection-02
> 
> Since I don’t fiddle with the TCP recovery code on a daily basis, I am a member of a large group of people who, in my opinion, can never make solid claims about the correctness of a mechanism like this one. All people like me can do is read and comment and hope for the best  :-)    because fully understanding this from simply reading, not looking at code, is REALLY hard. I don’t blame it on the authors: I appreciate that making this document easier to read must be very, very difficult.

Thanks for the comments! I have had bit similar thoughts than what you say above. TCP recovery engine with all its performance optimizations starts to be quite complex already, so it is hard to review various corner cases or interactions with other algorithms. I’m sure the authors have done thorough work in implementing and analysing the algorithm, but can the rest of us understand it sufficiently well? There are quite a few steps in the algorithm to be digested.

- Pasi