web

web - news - images - annuaire - compagnies + en plus

recherche avancée

Cache

ippm mail archive contents treno based bulk transfer capacity metric matt mathis (mathis@psc.edu) tue, 19 nov 1996 17:02:57 -0500 messages sorted by: [ date ][ thread ][ subject ][ author ] next message: guy t almes: "early draft of a one-way delay metric" previous message: guy t almes: "the way to san jose" attached is my first draft of a btc metric internet-draft. i running out of time so i am sort of rushing this out. please read and comment. i intend to post this as an i-d by the ietf deadline (tuesday nov 26th). the new version of treno (to go with this document) is not quite ready yet. i expect to post it later this week. is there somebody who would like to help by porting treno to sunos and/or solaris? i would much rather release a single version of the code with proper compile conditionals. i could also use some help from a document editor. any volunteers? thanks, --mm-- ---------------------------------------------------------------- empirical bulk transfer capacity -------------------------------- motivation: bulk transport capacity (btc) is a measure of a network's ability to transfer significant quantities of data with a single congestion aware transport connection (e.g. state-of-the-art tcp). for many applications the btc of the underlying network dominates the the overall elapsed time for the application, and thus dominates the performance as perceived by a user. the congestion control algorithm is crucial to the the btc metric. the internet depends on the end systems to fairly divide the available bandwidth on the basis of common congestion behavior. the btc metric is based on the performance of a reference congestion control algorithm that has particularly uniform and stable behavior. the reference algorithm is documented in appendix a, and can be implemented in tcp using the sack option [rfc2018]. since the behavior of the reference congestion control algorithm is well defined and implementation independent, it will be possible confirm that different measurements are are repeatable and comparable, and as such it will implement a true metric in the strongest sense of the word. implementing standard congestion control algorithms within the diagnostic eliminates calibrations problems associated with the non-uniformity of current tcp implementations. however, like all empirical metrics it introduces new problems, most notably the need to certify the correctness of the implementation and to verify that there are not systematic errors due to limitations of the tester. this version of the metric is based on the tool treno (pronounced tree-no), which implements the reference congestion control algorithm over either traceroute style udp and icmp messages or icmp ping packets. many of calibration checks can be included in the measurement process itself. the treno program includes error and warning messages for many conditions which indicate either problems with the infrastructure or in some cases problems with the measurement process. other checks need to be performed manually. ---------------------------------------------------------------- metric name: treno-type-p-bulk-transfer-capacity (e.g. treno-udp-btc) metric parameters: a pair of ip addresses, src (aka "tester") and dst (aka "target"), a start time t and initial mtu. definition: the average data rate attained by the reference congestion control algorithm, while using type-p packets to probe the forward (src to dst) path. in the case of icmp ping, these messages also probe the return path. metric units: bits per second ancillary results and output used to verify the proper measurement procedure and calibration: - statistics over the entire test (data transferred, duration and average rate) - statistics from the equilibrium portion of the test (data transferred, duration, average rate, and number of equilibrium congestion control cycles) - path property statistics (mtu, min rtt, max cwnd in equilibrium and max cwnd during slow-start) - statistics from the non-equilibrium portion of the test (nature and number of non-equilibrium events). - estimated load/bw/buffering used on the return path. - warnings about data transmission abnormalities. (e.g packets out-of-order) - warning about conditions which may effect metric accuracy. (e.g insufficient tester buffering) - alarms about serious data transmission abnormalities. (e.g. data duplicated in the network) - alarms about tester internal inconsistencies and events which might invalidate the results. - ip address/name of the responding target. - treno version. method: run the treno program on the tester with the chosen packet type addressed to the target. record both the btc and the ancillary results. manual calibration checks. (see detailed explanations below). - verify that the tester and target have sufficient raw bandwidth to sustain the test. - verify that the tester and target have sufficient buffering to support the window needed by the test. - verify that there is not any other system activity on the tester or target. - verify that the return path is not a bottleneck at the load needed to sustain the test. - verify that the ip address reported in the replys is some interface of the selected target. version control: - record the precise treno version (-v switch) - record the precise tester os version, cpu version and speed, interface type and version. discussion: we do not use existing tcp implementations due to a number of problems which make them difficult to calibrate as metrics. the reno congestion control algorithms are subject to a number of chaotic or turbulent behaviors which introduce non-uniform performance [floyd:retran, hoe:thesis, mathis:fack]. non-uniform performance introduces substantial non-calibratable uncertainty when used as a metric. furthermore a number of people [comer:testing, ??:testing, paxon:testing] have observed extreme diversity between different tcp implementations, raising doubts about repeatability and consistency between different tcp based measures. there are many possible reasons why a treno measurement might not agree with the performance obtained by a tcp based application. some key ones include: older tcp's missing key algorithms such as mtu discovery, support for large windows or sack, or mistuning of either the data source or sink. some network conditions which need the newer tcp algorithms are detected by treno and reported in the ancillary results. other documents will cover methods to diagnose the difference between treno and tcp performance. the discussion below assumes that the treno algorithm is implemented as a user mode program running under a standard operating system. other implementations, such as a dedicated measurement tool, can have stronger built in calibration checks. the raw performance (bandwidth) limitations of both the tester and target should be measured by running treno in a controlled environment (e.g. a bench test). idealy the observed performance limits should be validated by diagnosing the nature of the bottleneck and verifying that it agrees with other benchmarks of the tester and target (e.g. that treno performance agrees with direct measures of backplane or memory bandwidth or other bottleneck as appropriate.) these raw performance limitations may be obtained in advance and recorded for later reference. currently no routers are reliable targets, although under some conditions they can be used for meaningful measurements. for most people testing between a pair of modern computer systems at a few megabits per second or less, the tester and target are unlikely to be the bottleneck. treno may not be accurate, and should not be used as a formal metric at rates above half of the known tester or target limits. this is because during slow-start treno needs to be able to send bursts which are twice the average data rate. [need exception if the 1st hop lan is the limit in all cases?] verifying that the tester and target have sufficient buffering is difficult. if they do not have sufficient buffer space, then losses at their own queues may contribute to the apparent losses along the path. there several difficulties in verifying the tester and target buffer capacity. first, there are no good tests of the target's buffer capacity at all. second, all validation of the testers buffering depend in some way on the accuracy of reports by the tester's own operating system. third, there is the confusing result that in many circumstances (particularly when there is more than sufficient average performance) where insufficient buffering does not adversely impact measured performance. treno reports (as calibration alarms) any events where transmit packets were refused due to insufficient buffer space. it reports a warning if the maximum measured congestion window is larger than the reported buffer space. although these checks are likely to be sufficient in most cases they are probably not sufficient in all cases, and will be subject of future research. note that on a timesharing or multi-tasking system, other activity on the tester introduces burstyness due to operating system scheduler latency. therefore, it is very important that there be no other system activity during a test. this should be confirmed with other operating system specific tools. in traceroute mode, treno computes and reports the load on the return path. unlike real tcp, treno can not distinguish between losses on the forward and return paths, so idealy we want the return path to introduce as little loss as possible. the best way to test the return path is with treno icmp mode using ack sized messages, and verify that the measured packet rate is improved by a factor of two. [more research needed] in icmp mode treno measures the net effect of both the forward and return paths on a single data stream. bottlenecks and packet losses in the forward and return paths are treated equally. it would raise the accuracy of treno traceroute mode if the icmp ttl execeded messages were generated at the target and transmitted along the return path with elevated priority (reduced losses and queuing delays). people using the treno metric as part of procurement documents should be aware that in many circumstances mtu has an intrinsic and large impact on overall path performance. under some conditions the difficulty in meeting a given performance specifications is inversely proportional to the square of the path mtu. (e.g. halving the specified mtu makes meeting the bandwidth specification 4 times harder.) in metric mode, treno presents exactly the same load to the network as a properly tuned state-of-the-art tcp between the same pair of hosts. although the connection is not transferring useful data, it is no more wasteful than fetching an un-wanted web page takes the same time to transfer. ---------------------------------------------------------------- appendix a: currently the best existing description of the algorithm is in the "fack technical note" below http://www.psc.edu/networking/tcp.html. all invocations of "bounding parameters" will be reported as warnings. this document will be revised for treno and supplemented by a code fragment, including the congestion control algorithm. next message: guy t almes: "early draft of a one-way delay metric" previous message: guy t almes: "the way to san jose" | go back to the ippm mail archive index|

Retour aux résultats

LocoTrain est un site internet du groupe Web Trains : annonceurs - charte - copyright - droits juridiques/CNIL/Statistiques - presse - email. Toute reproduction est interdite sans autorisation de LocoTrain.