IETF Logo Mail Archive

Re: [tcpm] review of draft-zimmermann-tcpm-reordering-detection

"Zimmermann, Alexander" <Alexander.Zimmermann@netapp.com> Fri, 06 February 2015 18:46 UTC

Return-Path: <Alexander.Zimmermann@netapp.com>
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 826841A876B for <tcpm@ietfa.amsl.com>; Fri, 6 Feb 2015 10:46:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 D-ltorkEqnX5 for <tcpm@ietfa.amsl.com>; Fri, 6 Feb 2015 10:46:43 -0800 (PST)
Received: from mx143.netapp.com (mx143.netapp.com [216.240.21.24]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 566C31A19F0 for <tcpm@ietf.org>; Fri, 6 Feb 2015 10:46:43 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.09,530,1418112000"; d="asc'?scan'208";a="21411429"
Received: from hioexcmbx04-prd.hq.netapp.com ([10.122.105.37]) by mx143-out.netapp.com with ESMTP; 06 Feb 2015 10:41:42 -0800
Received: from HIOEXCMBX06-PRD.hq.netapp.com (10.122.105.39) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 6 Feb 2015 10:41:42 -0800
Received: from HIOEXCMBX06-PRD.hq.netapp.com ([::1]) by hioexcmbx06-prd.hq.netapp.com ([fe80::5ceb:17f1:1ecd:c4c9%21]) with mapi id 15.00.0995.031; Fri, 6 Feb 2015 10:41:42 -0800
From: "Zimmermann, Alexander" <Alexander.Zimmermann@netapp.com>
To: Wesley Eddy <wes@mti-systems.com>
Thread-Topic: [tcpm] review of draft-zimmermann-tcpm-reordering-detection
Thread-Index: AQHQQXzFva7VDhVhZUSRjwVCoGgnfpzjm8+AgAAGHQCAANo/AA==
Date: Fri, 06 Feb 2015 18:41:41 +0000
Message-ID: <71D50EDC-8253-4A5D-9FA2-D5C4BC34FD7C@netapp.com>
References: <54D3C911.6020205@mti-systems.com> <CAO249yejyCzC5TaMb2U9P3g_si4N-z+N1s21M4ohXqyZQvqyPw@mail.gmail.com> <54D453C4.7070107@mti-systems.com>
In-Reply-To: <54D453C4.7070107@mti-systems.com>
Accept-Language: de-DE, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.2070.6)
x-originating-ip: [10.120.60.36]
Content-Type: multipart/signed; boundary="Apple-Mail=_BE603F55-703B-4BD9-8D88-0A737704FDF9"; protocol="application/pgp-signature"; micalg="pgp-sha1"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tcpm/1oBqN-T-ej79nTix1SgUFADlFA0>
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] review of draft-zimmermann-tcpm-reordering-detection
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: Fri, 06 Feb 2015 18:46:47 -0000

Hi Wes,

> Am 06.02.2015 um 06:40 schrieb Wesley Eddy <wes@mti-systems.com>:
> 
> On 2/6/2015 12:18 AM, Yoshifumi Nishida wrote:
>> Hi,
>> I also agree that this document is well written and we already have seen
>> some consensus to explore solutions for reordering issue in the WG.
>> 
>> However, I personally have the following high-level questions on the
>> draft in order to think about it more.
>> 
>> Q1: Do we think that measuring reordering extent can be an approach for
>> reordering issue?
>>    One thing I'm wondering is that measured reordering extent is a kind
>> of historic data. So, to utilize this data properly, we might need to
>> understand how previous reorder extent is relevant to present or future
>> trends. Do we have some understandings or consensus on this? Or, can we
>> utilize this data in other ways?
>> 
> 
> 
> This is a good point, since reordering could be due to a transient
> that occurs once during a connection and never again (e.g. some
> change in the underlying path), or it could be persistent due to
> properties of the path fixed for the life of the connection.
> 
> It's difficult / impossible to tell the difference on a shorter
> connection, or even on many short connections between the same
> hosts, but if you could tell the difference, that would determine
> the proper use of the metrics.
> 
> In the 1st case, it doesn't seem like TCP should be doing anything
> beyond just reversing state changes made due to a spurious decision.
> 
> In the 2nd case, the reordering metrics that are measured would be
> useful to cache along with the other path metrics that are already
> cached.
> 

You are right. This discussion is currently missing in the (reaction
draft. I need to write a paragraph w/o a couple of recommendation in
which scenarios the non-adaptive mode may lead to better performance.
For example I run my experience in Linux, which has a (more or less)
proper undoing strategy. In case undoing is not implemented, the
adaptive mode could be have negative effects since you need a couple
reordering events (which will be let to spurious retransmissions) to
set the threshold appropriate.

Alex


> --
> Wes Eddy
> MTI Systems
> 
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

v2.23.0 | Report a Bug | By Email