Re: [ippm] Document Action: 'Test Plan and Results for Advancing RFC 2680 on the Standards Track' to Informational RFC (draft-ietf-ippm-testplan-rfc2680-05.txt)
"MORTON, ALFRED C (AL)" <acmorton@att.com> Fri, 23 May 2014 13:35 UTC
Return-Path: <acmorton@att.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5A101A01AF for <ippm@ietfa.amsl.com>; Fri, 23 May 2014 06:35:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level:
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001] 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 1k-pt3e5cgGf for <ippm@ietfa.amsl.com>; Fri, 23 May 2014 06:35:48 -0700 (PDT)
Received: from mail-pink.research.att.com (mail-pink.research.att.com [204.178.8.22]) by ietfa.amsl.com (Postfix) with ESMTP id E72D91A0020 for <ippm@ietf.org>; Fri, 23 May 2014 06:35:47 -0700 (PDT)
Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 2F75A120CAF; Fri, 23 May 2014 09:37:42 -0400 (EDT)
Received: from njfpsrvexg8.research.att.com (unknown [135.207.255.243]) by mail-blue.research.att.com (Postfix) with ESMTP id 4DEAAF03A3; Fri, 23 May 2014 09:35:46 -0400 (EDT)
Received: from NJFPSRVEXG8.research.att.com ([fe80::cdea:b3f6:3efa:1841]) by njfpsrvexg8.research.att.com ([fe80::cdea:b3f6:3efa:1841%13]) with mapi; Fri, 23 May 2014 09:35:45 -0400
From: "MORTON, ALFRED C (AL)" <acmorton@att.com>
To: "Ruediger.Geib@telekom.de" <Ruediger.Geib@telekom.de>
Date: Fri, 23 May 2014 09:35:43 -0400
Thread-Topic: [ippm] Document Action: 'Test Plan and Results for Advancing RFC 2680 on the Standards Track' to Informational RFC (draft-ietf-ippm-testplan-rfc2680-05.txt)
Thread-Index: Ac9t9C2z/k/uek7hSSSYWIbgKJJsXAAJZq3iAdxvCOAAP8ssIA==
Message-ID: <2845723087023D4CB5114223779FA9C8017992C146@njfpsrvexg8.research.att.com>
References: <1399907354.77429.YahooMailNeo@web125106.mail.ne1.yahoo.com> <2845723087023D4CB5114223779FA9C80178E0CD58@njfpsrvexg8.research.att.com> <CA7A7C64CC4ADB458B74477EA99DF6F502CC24A299@HE111643.EMEA1.CDS.T-INTERNAL.COM>
In-Reply-To: <CA7A7C64CC4ADB458B74477EA99DF6F502CC24A299@HE111643.EMEA1.CDS.T-INTERNAL.COM>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/ippm/AkrS_ex8cQgI8b4yFpy_mZTsNPQ
Cc: "ippm@ietf.org" <ippm@ietf.org>
Subject: Re: [ippm] Document Action: 'Test Plan and Results for Advancing RFC 2680 on the Standards Track' to Informational RFC (draft-ietf-ippm-testplan-rfc2680-05.txt)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 13:35:49 -0000
Hi Rüdiger, You haven't missed a deadline, and thanks for reviewing and commenting on the 2679bis and 2680bis memos! Others may wish to take a look, too: http://tools.ietf.org/html/draft-morton-ippm-2679-bis-04.txt http://tools.ietf.org/html/draft-morton-ippm-2680-bis-02.txt If more folks take a look and support these drafts for adoption/advancement, we can move these two fundamental metrics up the Standards Track (something of a milestone for IPPM - we haven't accomplished this yet for any of our metric RFCs). These are both reasonable updates to the information provided, IMO. regards, Al > -----Original Message----- > From: Ruediger.Geib@telekom.de [mailto:Ruediger.Geib@telekom.de] > Sent: Friday, May 23, 2014 3:47 AM > To: MORTON, ALFRED C (AL) > Cc: ippm@ietf.org > Subject: AW: [ippm] Document Action: 'Test Plan and Results for Advancing > RFC 2680 on the Standards Track' to Informational RFC (draft-ietf-ippm- > testplan-rfc2680-05.txt) > > Hi Al, > > I apologise for probably having missed the deadline. Some comments > applying to RFCs 2679 and 2680 informative sections. I don't insist on > these changes or my text proposals, but a review of the TCP related text > may be useful. > > Regards, Ruediger > > > > Section Motivation > > OLD + In today's Internet, the path from a source to a destination may be > different than the path from the destination back to the source > ("asymmetric paths"), ......Measuring each path independently > highlights the > performance difference between the two paths which may traverse > different Internet service providers, and even radically different > types of networks (for example, research versus commodity networks, > or ATM versus packet-over-SONET). > > NEW ......Measuring each path independently highlights the > performance difference between the two paths which may traverse > different Internet service providers, and even radically different > types of networks (for example, research versus commodity networks > or wireline access portion versus wireless one). > > The originally given example is outdated. Not sure about the quality of > the new one but access multiplexers definitely exist. > > > OLD + Performance of an application may depend mostly on the performance > in one direction. For example, a file transfer using TCP may depend > more on the performance in the direction that data flows, rather than > the direction in which acknowledgements travel. > > NEW: + Performance of an application may depend on the performance > in one direction. For example, a TCP based communication may experience > reduced throughput if congestion occurs in one direction of its > communication. > Trouble shooting is simplified, if the congested direction of a TCP > connection > can be directly identified. > > The old text may raise the impression that delaying ACKs by congestion or > dropping them has little impact on TCP throughput. That's not generally > true, > ACKs in a bloated buffer decrease the data flow performance. Bufferbloat > wasn't an issue when the RFCs were written.
- [ippm] Document Action: 'Test Plan and Results fo… The IESG
- Re: [ippm] Document Action: 'Test Plan and Result… MORTON, ALFRED C (AL)
- [ippm] Document Action: 'Test Plan and Results fo… Nalini Elkins
- Re: [ippm] Document Action: 'Test Plan and Result… MORTON, ALFRED C (AL)
- Re: [ippm] Document Action: 'Test Plan and Result… Ruediger.Geib
- Re: [ippm] Document Action: 'Test Plan and Result… MORTON, ALFRED C (AL)