From owner-ecm@wyvern.aciri.org Thu Aug 3 03:19:49 2000 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23914 for ; Thu, 3 Aug 2000 03:19:48 -0400 (EDT) Received: (from majordomo@localhost) by wyvern.aciri.org (8.9.3/8.9.3) id AAA60882 for ecm-outgoing; Thu, 3 Aug 2000 00:17:31 -0700 (PDT) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by wyvern.aciri.org (8.9.3/8.9.3) with ESMTP id AAA60877 for ; Thu, 3 Aug 2000 00:17:30 -0700 (PDT) (envelope-from vern@daffy.ee.lbl.gov) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.10.0/8.10.0) id e737HSq13365; Thu, 3 Aug 2000 00:17:28 -0700 (PDT) Message-Id: <200008030717.e737HSq13365@daffy.ee.lbl.gov> To: mankin@east.isi.edu, sob@harvard.edu Subject: summary for ECM Cc: ecm@aciri.org Date: Thu, 03 Aug 2000 00:17:27 PDT From: Vern Paxson Sender: owner-ecm@aciri.org Precedence: bulk ECM met Monday afternoon with about 170 people in attendance. The chair reviewed the status of the documents: congestion control principles is done and in the RFC editor's queue; the CM abstract API has been through last call, but the chair's request for WG members to state approval of the document yielded almost no response, so the document needs further discussion to attain consensus; the chair proposes that the separate document on correct congestion manager behavior is perhaps not needed, since draft-ietf-ecm-cm-01.txt already includes such discussion; and work has yet to begin on the document giving examples of possible schedulers. The bulk of the meeting was CM overview and discussion of pending issues led by Hari Balakrishnan. A number of issues were discussed, including the granularity of sharing, the coupling of information between the congestion controller and the schedulers, including variances in estimates provided by the CM, deployment motivations, how to retransmit when the loss leading to retransmission has cut cwnd to below the amount of outstanding data, handling of duplicate acknowledgements, and whether the abstract API should allow for sending multiple packets at one time. The chair proposed that with some document edits and resolution of the multiple packets issue via mailing list discussion, that the document would then be last-called once again, this time with a presumption of WG approval of the document once the last call completes. There was good WG support for this proposal. The meeting ended with a request from the chair for volunteers to work on the examples-of-schedulers document. From owner-ecm@wyvern.aciri.org Thu Aug 3 03:33:33 2000 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28335 for ; Thu, 3 Aug 2000 03:33:33 -0400 (EDT) Received: (from majordomo@localhost) by wyvern.aciri.org (8.9.3/8.9.3) id AAA60971 for ecm-outgoing; Thu, 3 Aug 2000 00:33:21 -0700 (PDT) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from daffy.ee.lbl.gov (daffy.ee.lbl.gov [131.243.1.31]) by wyvern.aciri.org (8.9.3/8.9.3) with ESMTP id AAA60966 for ; Thu, 3 Aug 2000 00:33:20 -0700 (PDT) (envelope-from vern@daffy.ee.lbl.gov) Received: (from vern@localhost) by daffy.ee.lbl.gov (8.10.0/8.10.0) id e737XKN13654; Thu, 3 Aug 2000 00:33:20 -0700 (PDT) Message-Id: <200008030733.e737XKN13654@daffy.ee.lbl.gov> To: ecm@aciri.org Subject: draft minutes for Monday's meeting Date: Thu, 03 Aug 2000 00:33:20 PDT From: Vern Paxson Sender: owner-ecm@aciri.org Precedence: bulk Many thanks to Aaron for putting these together. Please let us know if you have comments, corrections, clarifications, etc. Thanks, Vern Draft minutes for Endpoint Congestion Management WG meeting Monday, July 31 IETF 48, Pittsburgh Notes by Aaron Falk, with editing by Vern Paxson. The chair began the meeting with an overview of the WG's deliverables. The congestion control principles document is complete and in the RFC pipeline. The abstract CM API has completed WG last call. However, it appears that few people have read the document, leading the chair to wonder if there's been sufficient WG review to constitute consensus. A third deliverable is a document specifying correct behavior of a congestion controller. The chair proposed that the API document has sufficient discussion and pointers to previous documents to serve as such. No comments were heard in support or counter to this proposal. Hari Balakrishnan then lead an extensive overview of draft-ietf-ecm-cm-01.txt, using viewgraphs available from http://ms.lcs.mit.edu. Summary of the draft: the desire is to integrate CM across all applications -- not just TCP-based ones. It goes just above the IP layer and exposes an API that allows applications to get information about the state of the network. One issue that needs more discussion is: what should the granularity of a macroflow be? This was discussed at the Nov. 99 IETF. The default is to aggregate all streams to a given addresss. The grouping and ungrouping API allows this to be changed by an application program. Suggestion from the floor: why not let the application (cm_update) tell CM whether it's getting receiver feedback or not, rather than using terms for reporting loss like PERSISTENT and TRANSIENT, which allow too much ambiguity? Suggestion: give applications simple and non-ambiguous signals - e.g., it's receiving feedback; no-feedback; non-congestion-related loss. Vern asked why the grant time is in terms of RTT rather than RTO? Hari replied that RTO would not be appropriate because it's possible to build a TCP-friendly app without a notion of RTO. Hari proposed removing the notion of rttdev from the cm_query() call. Joe Touch suggested that any mechanism collecting data and reporting aggregate values should be calculating deviations to give a 'credibility weighting' to reported values. (I.e., to distinguish wildly varying values from stable ones). Joe also questioned the utility of reporting a rate if there's no information given as to the interval over which the rate is computed. Hari clarified that rates are over a small time window (i.e., one RTT). Two folks suggested that a jitter measurement would be useful in determining the aggregate jitter for things like RTP streams. This would allow applications to make adjustments using more information than just their individual RTP jitter measurements. Mark Handley suggested keeping rttdev to allow new TCPs access to the info when they start. Vern asked whether it should be defined the way TCP currently computes it (including using a deviation rather than a variance). Joe suggested that good statistics for the CM to report would be those pertaining to a group/macroflow rather than a single stream. Vern asked will there be part of the scheduler API the defines the scheduling discipline? The answer is Yes. Joe thought that an application should be able to use a single call of cm_get/setmacroflow() to forward some data to the scheduler, rather than requiring two calls from the app, one to the CM and one to the scheduler. He further emphasized that we really need a scheduler API in order to evaluate the completeness/adequacy of the CM API. cm_get/setmacroflow depends significantly on the choice of scheduler and it's not possible to evaluate the proposal without understanding the scheduler better. Vern stated that the concept was to nail down the CM part now to enable experimentation with schedulers. This is appropriate for Proposed Standard documents - there's plenty of leeway to change them, including recycling them at Proposed. Unattributed question: what will be the incentive for applications to use CM? Hari replied that they will attain better performance in situations such as slow start. Vern added that in the future the the IETF may require new protocols to use CM to for congestion management rather than inventing their own. Hari then raised a pending issue regarding temporarily overriding cwnd restrictions. Suppose a TCP loses a packet due to congestion. The sender calls cm_update(). This causes the CM to cut the window. Now, the outstanding data exceeds cwnd. So what happens to the retransmission? How does it manage to go out? One solution (hack): add a priority parameter to cm_request(), perhaps with the restriction of you can request at most one high-priority packet per RTT? Tim Shepard thought that solution was okay, but prefers FACK and rate-halving (which is more aggressive but allows you to keep sending packets). Hari agreed that if you use FACK, this isn't an issue, but we don't want to restrict implementors to doing a TCP-style congestion controller. Tim mentioned that another alternative would be to not change TCP, and only use CM for other apps. Sally Floyd asked for clarification regarding what does a TCP sender tell the CM when it receives dupacks? Answer: any dupack is treated as feedback that packets have left the pipe. Tim was also concerned with the default policy of grouping TCP connections together based on the same same src/dst IP addresses. NAT boxes may mask a lot of complexity behind a single IP dst addresses. Vern commented that this is a key issue and we are hoping to crystalize an IRTF effort to look at this. He also pointed out that the assumption of sharing network path properties based on common destination address is already in use today, in route caches that include ssthresh and rtt/rttvar information. Matt Mathis stated that if there's a NAT box the behavior will still be safe from a network stability perspective, though traffic may be slowed down unneccesarily. Joe mentioned that a slow link and fast link behind a NAT will result in two connections running at the average of the two rates. Matt countered that this will still result in behavior that is safe, because of loss incurred on the slow link slowing down the entire aggregate. There was further discussion about possibly pathological situations in which the slow link could in fact be overwhelmed; it was not clear how plausible these scenarios are. Sally mentioned that the CM could recognize when two connections sharing congestion control state have vastly different behaviors (RTT, loss rate), and could move one of the connections to a different macroflow. Vern then asked about a scenario in which the sender transmits 10 packets with TCP, and they all get lost, incurring a timeout. When does the CM know that nothing got through, and that it should adjust its notion of how much data is outstanding? Answer: the app tells the CM that it sent 10 packets, and based on the feedback it received (i.e., only implicit feedback due to a timeout), none were received. Joe Touch then raised the question of whether a more complex cm_request() interface is needed, one that can issue a request to send multiple packets. The context in which this comes up is attempting to run a connection very fast, say at 10 Gbps. In this case, a function call is as bad as a kernel crossing. There shouldn't be a correlation between the number of packets to send and the number of function calls. Matt countered that people who are running at that kind of rate are not going to want to do this kind of congestion aggregation anyway. Vern pointed out that we are defining an abstract API and not a concrete API, so a key question is to what degree would this change affect the abstract API we're documenting? Joe said we would need to delete the wording that the app must call cm_request() per packet. But Hari argued for keeping one call per packet or per MTU, in order to elimiate bursts of packets from being sent that locks out other users. Joe thinks this overhead is excessive. Hari suggested we could add something about back to back bursts, and asked Sally whether the congestion control principals document includes discussion of bursts. Answer: no, that document isn't meant to be a set of specific mechanisms. Her view is that additional congestion control mechanisms can be defined, and should perhaps be vetted by IETF process, either in ECM or TSV. The chair then made the following proposal for moving forward with ecm-cm-01: 1. Add opaque (scheduler) data to the API when creating a macroflow. 2. Add specification of how to compute the RTT variation. 3. Change CM_PERSISTENT to CM_LOST_FEEDBACK, etc. 4. Add a comment to the document that some key experience we don't yet have is with scheduling APIs, and that this may lead to possible changes in the CM API. 5. Resolve the issue Joe raised regarding sending multiple packets. After addressing these, there would be one more WG Last Call. The chair then asked for a show of WG consensus for this plan, with it being understood that the chair would interpret consensus for the plan followed by a successful last call as consensus for the document. A show of hands revealed good consensus and no opposition. The meeting finished with brief discussion of the Informational document the WG is tasked to produce giving example(s) of implementing one or more CM schedulers. The chair asked for volunteers to begin an outline of the document, right up a particular scheduling policy, or serve as editor, noting that the document is already overdue and the chair hopes to expedite it. There were no public volunteers, however. From owner-ecm@wyvern.aciri.org Mon Aug 7 08:30:49 2000 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26297 for ; Mon, 7 Aug 2000 08:30:48 -0400 (EDT) Received: (from majordomo@localhost) by wyvern.aciri.org (8.9.3/8.9.3) id CAA90670 for ecm-outgoing; Mon, 7 Aug 2000 02:26:09 -0700 (PDT) (envelope-from owner-ecm@smtp.aciri.org) Received: from babar.switch.ch (babar.switch.ch [130.59.4.2]) by wyvern.aciri.org (8.9.3/8.9.3) with ESMTP id CAA90665 for ; Mon, 7 Aug 2000 02:26:08 -0700 (PDT) (envelope-from simon@limmat.switch.ch) Received: (from leinen@localhost) by babar.switch.ch (8.9.3+Sun/8.9.3) id LAA05005; Mon, 7 Aug 2000 11:26:25 +0200 (MEST) X-Authentication-Warning: babar.switch.ch: leinen set sender to simon@limmat.switch.ch using -f To: Vern Paxson Cc: ecm@aciri.org Subject: Re: draft minutes for Monday's meeting References: <200008030733.e737XKN13654@daffy.ee.lbl.gov> X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7,F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z,@ttmwYVO7l`6OXXYR` From: Simon Leinen In-Reply-To: Vern Paxson's message of "Thu, 03 Aug 2000 00:33:20 PDT" Date: 07 Aug 2000 11:26:25 +0200 Message-ID: Lines: 12 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ecm@aciri.org Precedence: bulk >>>>> "vp" == Vern Paxson writes: > Hari Balakrishnan then lead an extensive overview of draft-ietf-ecm-cm-01.txt, > using viewgraphs available from http://ms.lcs.mit.edu. I think this should be http://nms.lcs.mit.edu/ Regards, -- Simon Leinen simon@babar.switch.ch SWITCH http://www.switch.ch/misc/leinen/ Who is General Failure & why's he reading my disk? From owner-ecm@wyvern.aciri.org Thu Aug 17 11:52:23 2000 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28975 for ; Thu, 17 Aug 2000 11:52:22 -0400 (EDT) Received: (from majordomo@localhost) by wyvern.aciri.org (8.9.3/8.9.3) id IAA41840 for ecm-outgoing; Thu, 17 Aug 2000 08:49:53 -0700 (PDT) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from mail.yourdomain.com (m319-mp1-cvx1a.man.ntl.com [62.252.197.63]) by wyvern.aciri.org (8.9.3/8.9.3) with SMTP id IAA41835; Thu, 17 Aug 2000 08:49:47 -0700 (PDT) (envelope-from announce@leisurewebcams.com) From: announce@leisurewebcams.com Message-Id: <200008171549.IAA41835@wyvern.aciri.org> Date: Thu, 17 Aug 2000 13:14:16 Subject: LeisureWebcams.com - See the World Sender: owner-ecm@aciri.org Precedence: bulk LeisureWebcams.com is a recently launched website specialising in providing free LIVE access to over 1,500 webcams and 2,000 Tourist Offices world wide. Check it out:- http://www.leisurewebcams.com/ This offers you the chance to check out live and frequently updated images of your chosen location through the webcams and get detailed local knowledge through the Tourist Offices. Along with booking holidays direct through our travel partner, there is the opportunity to sell your unwanted clothes and equipment through our free Swap Shop. There is a lot to see, so if you have enjoyed your trip through our site, do tell your friends and let us know through 'Your Views'. If you have any suggestions for the site, or queries, please feel free to contact me at cy@LeisureWebcams.com. I look forward to hearing from you. Kind regards, Charlie Yates MARKETING DIRECTOR LeisureWebcams.com From owner-ecm@wyvern.aciri.org Mon Aug 21 21:20:45 2000 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11781 for ; Mon, 21 Aug 2000 21:20:44 -0400 (EDT) Received: (from majordomo@localhost) by wyvern.aciri.org (8.9.3/8.9.3) id SAA76483 for ecm-outgoing; Mon, 21 Aug 2000 18:18:41 -0700 (PDT) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from VisibilityFX (mid-tgn-nen-vty36.as.wcom.net [216.192.69.36]) by wyvern.aciri.org (8.9.3/8.9.3) with SMTP id SAA76478 for ; Mon, 21 Aug 2000 18:18:32 -0700 (PDT) (envelope-from rauch@visibilityfx.com) Date: Mon, 21 Aug 2000 18:18:32 -0700 (PDT) From: Political Affairs Resource Kit To: Message-Id: <419.436759.88768171rauch@visibilityfx.com> Subject: Free, Interactive Refugees of the World Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: owner-ecm@aciri.org Precedence: bulk Content-Transfer-Encoding: 7bit The Public Affairs Resource Center of VisibilityFX (www.visibilityfx.com/PARK) introduces the Refugees of the World Screensaver. This quick loading screensaver features a stunning animated digital image of the world with statistical data on refugees around the world. It also includes an interactive test center to test your knowledge about refugee issues. This screensaver is the first and only Refugee screensaver and its yours, free! Simply fill out the form at (www.visibilityfx.com/PARK) and you will immediately be taken to the download area. As a kick off to its new Interactive web site VisibilityFX (www.visibilityFX.com) welcomes you to download the screensaver and while your at our site take a look around and observe the various services VisibilityFX can provide your organization. The site is very appealing, uses the latest technology, and features a wild Flash intro. Again, enjoy the screensaver and we hope to hear from you soon. This is a targeted mailing of VisibilityFX. If you have received this mailing in error or would like to be removed from the mailing list please send an email to remove@visibilityfx.com VisibilityFX 2230 George C. Marshall Drive 729 Falls Church, VA 22043 From owner-ecm@wyvern.aciri.org Mon Aug 28 00:16:53 2000 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17079 for ; Mon, 28 Aug 2000 00:16:51 -0400 (EDT) Received: (from majordomo@localhost) by wyvern.aciri.org (8.9.3/8.9.3) id VAA25430 for ecm-outgoing; Sun, 27 Aug 2000 21:12:52 -0700 (PDT) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from bpl1.mantraonline.com ([202.56.224.129]) by wyvern.aciri.org (8.9.3/8.9.3) with ESMTP id VAA25425 for ; Sun, 27 Aug 2000 21:12:44 -0700 (PDT) (envelope-from nsos@mantraonline.com) Received: from navendum ([202.56.223.156]) by bpl1.mantraonline.com (Netscape Messaging Server 4.15) with SMTP id G00BF201.XA0 for ; Mon, 28 Aug 2000 09:40:14 -0500 Message-ID: <022801c010a5$f8e55040$03000004@navendum> From: "nsos" To: Subject: NSOS Triggers & Drivers # 3 Date: Mon, 28 Aug 2000 09:36:27 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01AC_01C010D3.7009ACC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-ecm@aciri.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_01AC_01C010D3.7009ACC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable NSOS Triggers & Drivers # 3 =20 =20 Take Interest, Be Exact=20 & Enjoy Forever ! NSOS Triggers and Drivers- Ideas that have proven track record of = facilitating growth.=20 nsos@mantraonline.com ------=_NextPart_000_01AC_01C010D3.7009ACC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
NSOS Triggers & = Drivers #=20 3

 

 

 Take = Interest,

 Be Exact =

&

Enjoy Forever = !

NSOS Triggers and Drivers- Ideas = that have=20 proven track record of facilitating growth.

nsos@mantraonline.com

------=_NextPart_000_01AC_01C010D3.7009ACC0-- From owner-ecm@wyvern.aciri.org Tue Aug 29 23:54:46 2000 Received: from wyvern.aciri.org (wyvern.aciri.org [192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA07597 for ; Tue, 29 Aug 2000 23:54:46 -0400 (EDT) Received: (from majordomo@localhost) by wyvern.aciri.org (8.9.3/8.9.3) id UAA41278 for ecm-outgoing; Tue, 29 Aug 2000 20:52:37 -0700 (PDT) (envelope-from owner-ecm@smtp.aciri.org) X-Authentication-Warning: wyvern.aciri.org: majordomo set sender to owner-ecm@smtp.aciri.org using -f Received: from sendflowersamerica.com ([206.168.43.232]) by wyvern.aciri.org (8.9.3/8.9.3) with SMTP id UAA41267; Tue, 29 Aug 2000 20:52:32 -0700 (PDT) (envelope-from sfaquestions@sendflowersamerica.com) From: sfaquestions@sendflowersamerica.com Subject: FlowerFunds - Fund Raising Program Date: Tue, 29 Aug 2000 18:18:49 Message-Id: <656.321589.238680@sendflowersamerica.com> Sender: owner-ecm@aciri.org Precedence: bulk SendFlowersAmerica is proud to introduce FlowerFunds-- This unique new concept will provide an income flow for your organization for years to come. Your organization is invited to explore the possibilities of participating in FlowerFunds. $FlowerFunds is an individualized fund raising program for non-profit organizations and schools. $FlowerFunds are cash rebates that are paid to your organization each and every time an order is placed by your members and supporters. $The best part is that it costs your organization nothing to participate!! How it works: 1. When your members and supporters order flowers or gifts through sendflowersamerica they determine the price they want to pay; be it $30, $40, $50 or $1000. Since your members and supporters determine the price, they all can participate in this program. 2. Your organization receives 20% of the purchase price of the order. Say a husband buys his wife a $50 bouquet. Your organization will receive a $10 cash rebate. Nice. This program never ends. Each and every time there is an order placed by your memebers and supporters, your organization will receive the 20% cash rebate. That's a lot of FlowerFunds, and your organization stands to benefit from a findraiser unlike any other fundraiser. For more information call 1 800 SEND 123 or http://www.sendflowersamerica.com Imagine earning money for your organization by making someone smile :-)