From owner-ecm@wyvern.aciri.org Fri Jun 2 19:26:31 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 TAA16909 for ; Fri, 2 Jun 2000 19:26:29 -0400 (EDT) Received: (from majordomo@localhost) by wyvern.aciri.org (8.9.3/8.9.3) id QAA70509 for ecm-outgoing; Fri, 2 Jun 2000 16:23:51 -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 wind.lcs.mit.edu (wind.lcs.mit.edu [18.31.0.82]) by wyvern.aciri.org (8.9.3/8.9.3) with ESMTP id QAA70504 for ; Fri, 2 Jun 2000 16:23:50 -0700 (PDT) (envelope-from dga@wind.lcs.mit.edu) Received: (from dga@localhost) by wind.lcs.mit.edu (8.8.7/8.8.7) id TAA16079 for ecm@aciri.org; Fri, 2 Jun 2000 19:23:45 -0400 Message-Id: <200006022323.TAA16079@wind.lcs.mit.edu> Subject: TR on Congestion Manager implementation, with perf #s To: ecm@aciri.org Date: Fri, 2 Jun 2000 19:23:45 -0400 (EDT) From: "David G. Andersen" X-Mailer: ELM [version 2.5 PL2] 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 We just published a tech report describing our current implementation of the Congestion Manager (CM) architecture, with a collection of performance numbers both promising, and worthy of future discussion. The TR can be found at: http://wind.lcs.mit.edu/publications/MIT-LCS-TR-808.ps.gz (gzipped) or http://wind.lcs.mit.edu/publications/MIT-LCS-TR-808.ps (uncompressed) Some of the interesting points from the paper: - Implementing TCP with the CM results in virtually _no_ overhead with the currently proposed API from the internet-draft. As suggested by earlier TCP control block sharing work, the resulting sharing of congestion control information can result in measurable benefits for clients which exhibit web browser-like behavior of fetching multiple files sequentially. - User-level programs get various overheads due to extra system calls depending on the type of interaction they want with the CM; we've proposed a few ways to mitigate this overhead for busy, demanding applications by batching calls, but even without this, a moderate machine can still saturate an ethernet. - It works. :-) At this point, we've implemented several clients and servers atop the CM: - TCP - The vat audio tool - Several "toy" applications designed to test and show the behavior of the CM. We'll have a (hopefully final) draft of the I-D out to the list early next week with a few minor corrections resulting from our implementation experience. Note that the performance numbers shown in the TR are in reality an easy upper bound on the overhead imposed by the CM, and in no way a lower bound - the implementation methods we chose were not designed to grind excruiciatingly fine bits of performance from our system, but instead to be implementable and verifiable in a reasonable context. More completely API-transparent optimizations are certainly possible, but even without them, the performance and functionality is quite pleasing. Stay tuned, and send comments! -Dave -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ From owner-ecm@wyvern.aciri.org Fri Jun 2 20:13:05 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 UAA17424 for ; Fri, 2 Jun 2000 20:13:04 -0400 (EDT) Received: (from majordomo@localhost) by wyvern.aciri.org (8.9.3/8.9.3) id RAA70789 for ecm-outgoing; Fri, 2 Jun 2000 17:13:00 -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 mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by wyvern.aciri.org (8.9.3/8.9.3) with ESMTP id RAA70784 for ; Fri, 2 Jun 2000 17:12:59 -0700 (PDT) (envelope-from sisalem@fokus.gmd.de) Received: from wallace.fokus.gmd.de (wallace [193.175.132.42]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id CAA19378; Sat, 3 Jun 2000 02:10:43 +0200 (MET DST) Received: from localhost (dor@localhost) by wallace.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id CAA00518; Sat, 3 Jun 2000 02:12:47 +0200 (MET DST) Date: Sat, 3 Jun 2000 02:12:47 +0200 (MET DST) From: Dorgham Sisalem To: "Dr. Injong Rhee" cc: Hari Balakrishnan , end2end-interest@isi.edu, ecm@aciri.org, bansal@lcs.mit.edu, hari@breeze.lcs.mit.edu Subject: Re: A family of TCP-friendly congestion control algorithms In-Reply-To: <10005291025.ZM5229@unity.ncsu.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ecm@aciri.org Precedence: bulk while we are at it, I would like to also announce our TCP-friendly control scheme called LDA+ (Enhanced Loss Delay-Based Adaptation Scheme). The following is a short paper with the description of the scheme, measurement results over the Internet and comparisons to some other schemes (RAP, TFRCP -the older version). The paper will appear in NOSSDAV'2000 ftp://ftp.fokus.gmd.de/pub/glone/papers/Sisa0007:TCP.ps Regards Dorgham --- Dorgham Sisalem email: sisalem@fokus.gmd.de GMD-Fokus phone: ++49 30 34 63 71 70 Kaiserin-Augusta-Allee 31 fax: ++49 30 34 63 81 70 D-10589 Berlin URL: http://www.fokus.gmd.de/usr/sisalem From owner-ecm@wyvern.aciri.org Thu Jun 8 12:55:06 2000 Received: from wyvern.aciri.org ([192.150.187.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11950 for ; Thu, 8 Jun 2000 12:55:06 -0400 (EDT) Received: (from majordomo@localhost) by wyvern.aciri.org (8.9.3/8.9.3) id JAA14043 for ecm-outgoing; Thu, 8 Jun 2000 09:52:14 -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 mta5.rcsntx.swbell.net (mta5.rcsntx.swbell.net [151.164.30.29]) by wyvern.aciri.org (8.9.3/8.9.3) with ESMTP id JAA14033 for ; Thu, 8 Jun 2000 09:52:13 -0700 (PDT) (envelope-from zainprov@swbell.net) From: zainprov@swbell.net Received: from zainprov ([207.193.24.81]) by mta5.rcsntx.swbell.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9) with SMTP id <0FVU00D3BFA52U@mta5.rcsntx.swbell.net> for ecm@aciri.org; Thu, 8 Jun 2000 11:06:02 -0500 (CDT) Date: Thu, 08 Jun 2000 11:06:02 -0500 (CDT) Date-warning: Date header was inserted by mta5.rcsntx.swbell.net Subject: Shocking LOSE 10-100lbs. DESTINY To: ecm@aciri.org Message-id: <0FVU00DLSFE02U@mta5.rcsntx.swbell.net> MIME-version: 1.0 Content-type: text/plain; charset=unknown-8bit Sender: owner-ecm@aciri.org Precedence: bulk Hello From Destiny, You will LOOSE 20-100 pounds easy! Do to Such a high demand for Destiny, we are able To Dramatically reduce our price for the entire System! You will LOVE our incredible offer on this Scientific Breakthrough in Weight Loss. Now with a 105% Money Back Guarantee! LOOK! http://home.swbell.net/zainprov/destiny.htm We hope things are going well for you. Good luck, God Bless, and HAVE A GREAT DAY! Either you are someone else subscribed to our list. To be removed Simply reply with a blank email. Thank you, Sherry Wilson From owner-ecm@wyvern.aciri.org Fri Jun 16 18:48:47 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 SAA27231 for ; Fri, 16 Jun 2000 18:48:46 -0400 (EDT) Received: (from majordomo@localhost) by wyvern.aciri.org (8.9.3/8.9.3) id PAA77324 for ecm-outgoing; Fri, 16 Jun 2000 15:47:34 -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 PAA77319 for ; Fri, 16 Jun 2000 15:47:34 -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 e5GMlYf06115; Fri, 16 Jun 2000 15:47:34 -0700 (PDT) Message-Id: <200006162247.e5GMlYf06115@daffy.ee.lbl.gov> To: ecm@aciri.org Subject: comments on draft-balakrishnan-cm-02.txt Cc: hari@lcs.mit.edu, sseshan@us.ibm.com Date: Fri, 16 Jun 2000 15:47:33 PDT From: Vern Paxson Sender: owner-ecm@aciri.org Precedence: bulk > FLOW > A stream of packets that all share the same source and > destination IP address, IP type-of-service, transport > protocol, and source and destination transport port numbers. This term is too easily confused with "macroflow" (there are places in the document where this happens). The document should just use "stream", which in its definition is noted as being in one-to-one correspondence with the notion of "flow", anyway. > MACROFLOW > A group of flows that uses the same congestion management and > scheduling algorithms, and shares congestion state > information. Flows destined to different receivers MUST belong > to different macroflows. I don't think the definition of macroflow should hardwire this last requirement. We may eventually wind up with mechanisms that unify flows across multiple destinations. This could be fixed by simply adding the word "Currently" at the beginning of the sentence, to flag that this notion may change. > CONGESTION WINDOW (cwnd) > A CM state variable that modulates the amount of outstanding > data between sender and receiver. Should there also be a definition for ssthresh? > transmit a heterogeneous types of data to receivers, ranging from Delete 'a'. > implementing the algorithms in [Jacobson88, Stevens97]), the Citation to Stevens97 should be updated to RFC 2581. (This occurs elsewhere, too.) > A future document will > describe the sender-receiver protocol and header formats that will > handle applications that do not incorporate their own feedback to > the CM. (This document focuses on well-behaved applications.) Could delete the parenthetical comment, or else modify it to make it clear that "This document" means the current one, not the future one that was just discussed. > 4. CM API It's important that all of the discussion of APIs in this document emphasizes that we're referring to *abstract* APIs. > 1. Open: All applications MUST call cm_open(u32 dst) before using > the CM API. dst is the 32-bit IPv4 address. This returns an There needs to be an IPv6 interface, too. > 2. Close: When a flow terminates, the application SHOULD invoke > cm_close(i32 cm_flowid) to inform the CM about the termination > of the flow. Per the comments above, change cm_flowid to cm_streamid. > information may either be statically configured, or obtained via > path MTU discovery [Mogul90]. Shouldn't doing PMTU-D be a SHOULD? > If a stream > does not transmit any data upon a cmapp_send() callback invocation, > it SHOULD call cm_notify(dst, 0) to allow the CM to permit other > flows in the macroflow to transmit data. Why give it any sort of leeway here? If the the app doesn't call cm_notify(), what ensures that the bookkeeping will stay consistent? (Or is the SHOULD to emphasize that correct operation of the controller shouldn't rely on the didn't-send notification, because it's an easy mistake for the app to make?) > One of the decisions the CM needs to make is the granularity at a "at a" should be "at which a" > includes a Congestion Controller and a Scheduler, with well-defined > interfaces exported by them. (here's another place that *abstract* needs to be mentioned) > The control algorithm decides when and how > much data can be transmitted by a flow. (here's an instance where "flow" should be "macroflow") > It uses application > notifications (Section 4.3) from concurrent streams on the same > macroflow to build up information about the congestion state of the > different network paths. It's not clear what's meant by "different network paths" here. Different paths taken by the elements of the same macroflow? Or is this simply a comment that there will be multiple macroflows? If the latter, then I suggest deleting it. > The congestion control module MUST implement the following > interfaces (these are not directly visible to applications; they > are within the context of a macroflow): If they're not directly visible, then why *must* the congestion control module implement them? If it's to provide for modular interoperability with different, separately-developed schedulers, then that should be stated. Also, the parenthetical comment is important and should be more emphasized. Otherwise the reader gets confused to how these routines are in fact different from the ones discussed earlier. > - void query(u64 *rate, u32 *srtt): This function returns the > estimated rate (in bits per second) and smoothed round trip time > (in microseconds) for the macroflow. Shouldn't it also return rttdev? > - void schedule(u32 num_bytes): When the congestion control module > determines that data can be sent, the schedule() routine MUST be > called with the number of bytes that can be sent. This MUST reads a little funny to me. Is the point that it shouldn't be calle with *no more* bytes than the number that can be sent? If so, then phrasing it "with no more than the number ..." would make it read a little better. > congestion control provides the information to satisfy an "control" should be "controller" > - void notify(u32 nsent): This interface is used to notify the > scheduler module whenever data is sent by a CM application. The > nsent parameter indicates the number of bytes just sent by the > application. Shouldn't the call include the flowid (streamid)? That would simplify the scheduler's state management. > outstanding window (tcp_ownd) estimate. Whenever, data is sent from Delete comma. > perform all non-congestion checks (nagle, receiver advertised Capitalize Nagle. > 4. The cmapp_send() callback for TCP is set to a simple output > routine. Is this really that simple? Doesn't it need to compute TCP header fields, possibly timestamps, etc? > The IP output routines on the host calls cm_notify() when the data > is actually sent out. How does it know which flowid/streamid is responsible? > that a packet was lost and that at least 3 packets reached to I think "arrived" is more clear than "reached". > Therefore, it calls > cm_update(flowid, 4 * avg_pkt_size, 3 * avg_pkt_size, > CM_TRANSIENT, rtt). This needs careful explanation. Also, why is it okay to use avg_pkt_size instead of computing the actual sizes? If this is a general principle, then there needs to be a section explaining it as such. > 5. Upon the arrival of a partial acknowledgment (one that does > not exceed that last segment transmitted at the time the loss "that last segment" should be "the last segment". Or should this be "the highest segment"? > When the source first starts, it uses the cm_query() call to get an > initial estimate of network bandwidth and delay. But there won't actually be an initial estimate available, will there? (unless some other streams have already been active) > To use the CM, the application must incorporate feedback from the > receiver. Seems this "must" should be a MUST. > 7. Security considerations > > The provides many of the same services that the congestion control ^CM > congestion, an attacker reduce the performance observed by add "can" before "reduce" From owner-ecm@wyvern.aciri.org Fri Jun 16 18:48: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 SAA27242 for ; Fri, 16 Jun 2000 18:48:48 -0400 (EDT) Received: (from majordomo@localhost) by wyvern.aciri.org (8.9.3/8.9.3) id PAA77296 for ecm-outgoing; Fri, 16 Jun 2000 15:45:34 -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 PAA77291 for ; Fri, 16 Jun 2000 15:45:33 -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 e5GMjX406062; Fri, 16 Jun 2000 15:45:33 -0700 (PDT) Message-Id: <200006162245.e5GMjX406062@daffy.ee.lbl.gov> To: ecm@aciri.org Cc: hari@lcs.mit.edu, sseshan@us.ibm.com, mankin@east.isi.edu Subject: ECM last call for draft-balakrishnan-cm-02.txt to Proposed Standard Date: Fri, 16 Jun 2000 15:45:33 PDT From: Vern Paxson Sender: owner-ecm@aciri.org Precedence: bulk ECM has been idle for a long time and I'd like to try to push things forward. Here's my plan (which I've discussed with the ADs): - Today starts a 3-week last call, expiring July 7th, for publishing draft-balakrishnan-cm-02.txt as Proposed. - In the next message I'm sending a number of comments on the document. I'd like to begin discussing these immediately, as I'm away (offline) on vacation June 20 - July 1, but of course they can also be discussed while I'm away, too. - After the last call closes, the authors will have 7 days to rev the document to make the Pittsburgh I-D cutoff. That version should be issued as draft-ietf-ecm-XXX-00.txt (maybe "XXX" should simply be "cm"). If they won't have cycles then, then someone else can take a hand at editing it. - At Pittsburgh, we hammer out any final issues with the document, and formulate a schedule (with some micro-deadlines) for completing the WG work. See you in Pittsburgh, Vern From owner-ecm@wyvern.aciri.org Wed Jun 21 08:28: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 IAA28671 for ; Wed, 21 Jun 2000 08:28:33 -0400 (EDT) Received: (from majordomo@localhost) by wyvern.aciri.org (8.9.3/8.9.3) id FAA12225 for ecm-outgoing; Wed, 21 Jun 2000 05:23:15 -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 ns.sait.samsung.co.kr (ns.sait.samsung.co.kr [202.20.142.13]) by wyvern.aciri.org (8.9.3/8.9.3) with ESMTP id FAA12220 for ; Wed, 21 Jun 2000 05:23:14 -0700 (PDT) (envelope-from athene@sait.samsung.co.kr) Received: from jinchoi ([75.2.35.121]) by ns.sait.samsung.co.kr (8.9.3/8.9.3) with SMTP id VAA18520 for ; Wed, 21 Jun 2000 21:20:32 +0900 (KST) Message-ID: <003101bfdb7d$1cf6e240$7923024b@sait.samsung.co.kr> From: "jinchoi" To: Subject: QoS in switches with input buffering Date: Wed, 21 Jun 2000 21:34:53 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ecm@aciri.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi All Usually output buffered switch is used for QoS. But I am interested in how to provide QoS in switches with input buffering. Is there any research result for implementing QoS with Input Queuing? I will appreciate any pointers. Thanks JinHyeock Choi