--- 1/draft-ietf-ippm-model-based-metrics-09.txt 2017-02-28 15:13:12.281541206 -0800 +++ 2/draft-ietf-ippm-model-based-metrics-10.txt 2017-02-28 15:13:12.389543776 -0800 @@ -1,19 +1,19 @@ IP Performance Working Group M. Mathis Internet-Draft Google, Inc Intended status: Experimental A. Morton -Expires: August 31, 2017 AT&T Labs - February 27, 2017 +Expires: September 1, 2017 AT&T Labs + February 28, 2017 Model Based Metrics for Bulk Transport Capacity - draft-ietf-ippm-model-based-metrics-09.txt + draft-ietf-ippm-model-based-metrics-10.txt Abstract We introduce a new class of Model Based Metrics designed to assess if a complete Internet path can be expected to meet a predefined Target Transport Performance by applying a suite of IP diagnostic tests to successive subpaths. The subpath-at-a-time tests can be robustly applied to critical infrastructure, such as network interconnections or even individual devices, to accurately detect if any part of the infrastructure will prevent paths traversing it from meeting the @@ -57,21 +57,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on August 31, 2017. + This Internet-Draft will expire on September 1, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -202,21 +202,25 @@ 1.1. Version Control RFC Editor: Please remove this entire subsection prior to publication. Please send comments about this draft to ippm@ietf.org. See http://goo.gl/02tkD for more information including: interim drafts, an up to date todo list and information on contributing. - Formatted: Mon Feb 27 13:49:06 PST 2017 + Formatted: Tue Feb 28 14:24:28 PST 2017 + + Changes since -09 draft: + + o Five last minute editing nits. Changes since -08 draft: o Language, spelling and usage nits. o Expanded the abstract describe the models. o Remove superfluous standards like language o Remove superfluous "future technology" language. o Interconnects -> network interconnections. o Added more labels to Figure 1. o Defined Bulk Transport. @@ -391,21 +395,21 @@ traffic. Section 7 describes packet transfer statistics and methods to test them against the statistical criteria provided by the mathematical models. Since the statistical criteria typically apply to the complete path (a composition of subpaths) [RFC6049], in situ testing requires that the end-to-end statistical criteria be apportioned as separate criteria for each subpath. Subpaths that are expected to be bottlenecks would then be permitted to contribute a larger fraction of the end-to-end packet loss budget. In compensation, subpaths that - to not exhibit bottlenecks have must be constrained to contribute + to not expected exhibit bottlenecks must be constrained to contribute less packet loss. Thus the statistical criteria for each subpath in each test of a TIDS is an apportioned share of the end-to-end statistical criteria for the complete path which was determined by the mathematical model. Section 8 describes the suite of individual tests needed to verify all of required IP delivery properties. A subpath passes if and only if all of the individual IP diagnostic tests pass. Any subpath that fails any test indicates that some users are likely to fail to attain their Target Transport Performance under some conditions. In @@ -1133,22 +1137,22 @@ test paths, even when some subpath has a flaw. The definitions in Section 3 are sufficient for most test streams. We describe the slowstart and standing queue test streams in more detail. In conventional measurement practice stochastic processes are used to eliminate many unintended correlations and sample biases. However MBM tests are designed to explicitly mimic temporal correlations caused by network or protocol elements themselves. Some portions of - these system, such as traffic arrival (test scheduling) are naturally - stochastic. Other behaviors, such as back-to-back packet + these systems, such as traffic arrival (test scheduling) are + naturally stochastic. Other behaviors, such as back-to-back packet transmissions, are dominated by implementation specific deterministic effects. Although these behaviors always contain non-deterministic elements and might be modeled stochastically, these details typically do not contribute significantly to the overall system behavior. Furthermore, it is known that real protocols are subject to failures caused by network property estimators suffering from bias due to correlation in their own traffic. For example TCP's RTT estimator used to determine the Retransmit Time Out (RTO), can be fooled by periodic cross traffic or start-stop applications. For these reasons many details of the test streams are specified deterministically. @@ -1653,27 +1657,27 @@ loss recovery problematic for the transport protocol. Non-linear, erratic or excessive RTT increases suggest poor interactions between the channel acquisition algorithms and the transport self clock. All of the tests in this section use the same basic scanning algorithm, described here, but score the link or subpath on the basis of how well it avoids each of these problems. Some network technologies rely on virtual queues or other techniques to meter traffic without adding any queuing delay, in which case the data rate will vary with the window size all the way up to the onset - of load induced packet loss or ECN CE marks. For theses - technologies, the discussion of queuing in Section 6.3 does not - apply, but it is still necessary to confirm that the onset of losses - or ECN CE marks be at an appropriate point and progressive. If the - network bottleneck does not introduce significant queuing delay, - modify the procedure described in Section 6.3 to start scan at a - window equal to or slightly smaller than the test_window. + of load induced packet loss or ECN CE marks. For these technologies, + the discussion of queuing in Section 6.3 does not apply, but it is + still necessary to confirm that the onset of losses or ECN CE marks + be at an appropriate point and progressive. If the network + bottleneck does not introduce significant queuing delay, modify the + procedure described in Section 6.3 to start scan at a window equal to + or slightly smaller than the test_window. Use the procedure in Section 6.3 to sweep the window across the onset of queuing and the onset of loss. The tests below all assume that the scan emulates standard additive increase and delayed ACK by incrementing the window by one packet for every 2*target_window_size packets delivered. A scan can typically be divided into three regions: below the onset of queuing, a standing queue, and at or beyond the onset of loss. Below the onset of queuing the RTT is typically fairly constant, and @@ -1763,25 +1767,25 @@ Some historical half duplex technologies had the property that each direction held the channel until it completely drained its queue. When a self clocked transport protocol, such as TCP, has data and ACKs passing in opposite directions through such a link, the behavior often reverts to stop-and-wait. Each additional packet added to the window raises the observed RTT by two packet times, once as it passes through the data path, and once for the additional delay incurred by the ACK waiting on the return path. The duplex self interference test fails if the RTT rises by more than - a fixed bound above the expected queugit staing time computed from - trom the excess window divided by the subpath IP Capacity. This - bound must be smaller than target_RTT/2 to avoid reverting to stop - and wait behavior. (e.g. Data packets and ACKs both have to be - released at least twice per RTT.) + a fixed bound above the expected queuing time computed from the + excess window divided by the subpath IP Capacity. This bound must be + smaller than target_RTT/2 to avoid reverting to stop and wait + behavior. (e.g. Data packets and ACKs both have to be released at + least twice per RTT.) 8.3. Slowstart tests These tests mimic slowstart: data is sent at twice the effective bottleneck rate to exercise the queue at the dominant bottleneck. 8.3.1. Full Window slowstart test This is a capacity test to confirm that slowstart is not likely to exit prematurely. Send slowstart bursts that are target_window_size