From owner-ecm@wyvern.aciri.org Thu Apr 6 16:37:59 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 QAA14399 for ; Thu, 6 Apr 2000 16:37:58 -0400 (EDT) Received: (from majordomo@localhost) by wyvern.aciri.org (8.9.3/8.9.3) id NAA92692 for ecm-outgoing; Thu, 6 Apr 2000 13:35:05 -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 hns3.hns.com (hns3.hns.com [208.236.67.3]) by wyvern.aciri.org (8.9.3/8.9.3) with ESMTP id NAA92674 for ; Thu, 6 Apr 2000 13:35:04 -0700 (PDT) (envelope-from border@hns.com) Received: from hnssysa.hns.com (hnssysa.hns.com [139.85.76.100]) by hns3.hns.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA20093; Thu, 6 Apr 2000 16:30:28 -0400 (EDT) Received: from hns.com (alta14.hns.com [139.85.62.34]) by hnssysa.hns.com (8.9.0/8.8.7) with ESMTP id QAA01481; Thu, 6 Apr 2000 16:34:29 -0400 (EDT) Message-ID: <38ECF4D4.B94ABBC8@hns.com> Date: Thu, 06 Apr 2000 16:34:28 -0400 From: John Border X-Mailer: Mozilla 4.61 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: hari@lcs.mit.edu, sseshan@us.ibm.com CC: ecm@aciri.org Subject: CM MACROFLOWs versus DiffServ and MPLS References: <199911300040.QAA29976@daffy.ee.lbl.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ecm@aciri.org Precedence: bulk Content-Transfer-Encoding: 7bit The Congestion Manager draft suggests that FLOWs between the same two end points which experience identical congestion behavour in the Internet SHOULD belong to the same MACROFLOW. This makes sense. But, with DiffServ and MPLS (and perhaps other mechanisms) now providing the means for FLOWs between two hosts to take different paths, it appears difficult for a host to know which FLOWs to group together into MACROFLOWs. Having the host set its own initial DSCP would help but would still not completely address the issue. The latest (-02) Congestion Manager draft basically defers this issue as future work. But, the concept of a MACROFLOW seems fundamental to the CM idea so I was wondering if you (or someone else on the mailing list who has spent some time thinking about this) could summarize the current thinking re this issue in a couple of paragraphs... John Border Hughes Network Systems From owner-ecm@wyvern.aciri.org Tue Apr 11 14:12:32 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 OAA15540 for ; Tue, 11 Apr 2000 14:12:30 -0400 (EDT) Received: (from majordomo@localhost) by wyvern.aciri.org (8.9.3/8.9.3) id LAA33129 for ecm-outgoing; Tue, 11 Apr 2000 11:08:06 -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 arpeggio.lcs.mit.edu (arpeggio.lcs.mit.edu [18.26.0.42]) by wyvern.aciri.org (8.9.3/8.9.3) with ESMTP id LAA33124 for ; Tue, 11 Apr 2000 11:08:05 -0700 (PDT) (envelope-from dcurtis@arpeggio.lcs.mit.edu) Received: (from dcurtis@localhost) by arpeggio.lcs.mit.edu (8.9.1/8.9.1) id OAA25994; Tue, 11 Apr 2000 14:08:02 -0400 (EDT) Date: Tue, 11 Apr 2000 14:08:02 -0400 (EDT) From: Dorothy Curtis Message-Id: <200004111808.OAA25994@arpeggio.lcs.mit.edu> To: border@hns.com Subject: Re: CM MACROFLOWs versus DiffServ and MPLS Cc: ecm@aciri.org Sender: owner-ecm@aciri.org Precedence: bulk Hi - I am writing in response to your (John Border's) question about how the CM MACROFLOW concept would fit into the DiffServ world. In my understanding of the DiffServ world, routers have access to information, such as a corporate database, that specifies how FLOWs should be treated. It seems reasonable to me that the CM could also have access to such a database and use that information to aggregate FLOWs into MACROFLOWS and to label FLOWs so that they are processed appropriately within the network. (Note: a router might choose not to trust the CM's aggregation (labelling) and then should make its independent decisions based on its independent access to information in a database.) In the meantime, in the absence of such a database, the CM aggregates FLOWs into MACROFLOWs based on the destination host of the FLOWs. Dorothy Curtis MIT/LCS Date: Thu, 06 Apr 2000 16:34:28 -0400 From: John Border To: hari@lcs.mit.edu, sseshan@us.ibm.com CC: ecm@aciri.org Subject: CM MACROFLOWs versus DiffServ and MPLS References: <199911300040.QAA29976@daffy.ee.lbl.gov> The Congestion Manager draft suggests that FLOWs between the same two end points which experience identical congestion behavour in the Internet SHOULD belong to the same MACROFLOW. This makes sense. But, with DiffServ and MPLS (and perhaps other mechanisms) now providing the means for FLOWs between two hosts to take different paths, it appears difficult for a host to know which FLOWs to group together into MACROFLOWs. Having the host set its own initial DSCP would help but would still not completely address the issue. The latest (-02) Congestion Manager draft basically defers this issue as future work. But, the concept of a MACROFLOW seems fundamental to the CM idea so I was wondering if you (or someone else on the mailing list who has spent some time thinking about this) could summarize the current thinking re this issue in a couple of paragraphs... John Border Hughes Network Systems From owner-ecm@wyvern.aciri.org Tue Apr 11 15:49:30 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 PAA18710 for ; Tue, 11 Apr 2000 15:49:30 -0400 (EDT) Received: (from majordomo@localhost) by wyvern.aciri.org (8.9.3/8.9.3) id MAA33702 for ecm-outgoing; Tue, 11 Apr 2000 12:46:59 -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 breeze.lcs.mit.edu (breeze.lcs.mit.edu [18.31.0.83]) by wyvern.aciri.org (8.9.3/8.9.3) with ESMTP id MAA33697; Tue, 11 Apr 2000 12:46:57 -0700 (PDT) (envelope-from hari@breeze.lcs.mit.edu) Received: from breeze.lcs.mit.edu (hari@localhost [127.0.0.1]) by breeze.lcs.mit.edu (8.8.7/8.8.7) with ESMTP id PAA11544; Tue, 11 Apr 2000 15:46:31 -0400 Message-Id: <200004111946.PAA11544@breeze.lcs.mit.edu> X-Mailer: exmh version 2.0.2 Reply-To: Hari Balakrishnan X-url: http://wind.lcs.mit.edu/~hari/ To: border@hns.com cc: ecm@aciri.org, ddc@lcs.mit.edu, floyd@aciri.org Subject: Re: CM MACROFLOWs versus DiffServ and MPLS In-reply-to: Your message of "Tue, 11 Apr 2000 14:08:02 EDT" <200004111808.OAA25994@arpeggio.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Apr 2000 15:46:31 -0400 From: Hari Balakrishnan Sender: owner-ecm@aciri.org Precedence: bulk John, The fundamental problem behind the issue you bring up is a relatively hard research question. What we are looking for is a way by which the sender (with feedback from the receiver) can correctly infer which flows share a common path. What makes this hard is that we would like to do this: (i) without any additional traffic, (ii) without really modifying the timing of packet transmissions (e.g., by picking packet times so the source looks Poisson), since that may violate congestion control and/or lead to degraded performance, (iii) fast. Within a few RTTs, (iv) without false negatives. I.e., two flows shouldn't be deemed in the same macroflow if they do not share the same congestion points. Devising an end-to-end inference scheme that meets all of these conditions is an open research problem at this time. However, I feel comfortable thinking that these problems will be solved in some practical (probably non-ideal) way before Diffserv gets widely deployed. ***Rant begins here... As a person who firmly believes in the Internet architecture being a successful example of an end-to-end argument, I cannot help but feel that some of the practical aspects of diffserv violate this principle. When the network starts doing things to an end-to-end transmission protocol completely unbeknownst to that higher layer, it starts to violate some of the assumptions made by that layer. For example, if an ISP sets a DS codepoint at a (congested) edge by looking at a TCP port number or URL or some such, we have a potential problem---esp. if that ISP sends packets on the same macroflow along different (possibly congested) paths. The application and end-to-end transport layers do in fact know what the characteristics of the application are, and it would be good to think in terms of a simple in-band signaling mechanism by which application/transport characteristics or "desires" are reflected to the network layer to make a more informed decision (e.g., about DS codepoint), without an egregious layering "violation," and develop an architecture where informed network decisions are made to maximize ISP revenue, without ignoring the best interests of the end-systems. One more thing---the CM does have API calls by which an application can declare a set of flows to be in the same macroflow (e.g., concurrent HTTP/TCP connections). Unfortunately, it cannot prevent a router downstream from looking at the transport layer port number and URL and the phase of the moon :) to hash the flow to a certain DS codepoint or a certain link/route. Unless we extend the architecture to include advisory information (which, by the way, is also needed for a clean way to ensure that packets belonging to the same TCP connections are sent along the same path, for otherwise much hell will break loose), I don't see an architecturally elegant solution. Hari On Tue, 11 Apr 2000 14:08:02 EDT, you wrote: > Hi - > > I am writing in response to your (John Border's) question about how > the CM MACROFLOW concept would fit into the DiffServ world. > > In my understanding of the DiffServ world, routers have access to > information, such as a corporate database, that specifies how FLOWs > should be treated. It seems reasonable to me that the CM could also have > access to such a database and use that information to aggregate > FLOWs into MACROFLOWS and to label FLOWs so that they are processed > appropriately within the network. (Note: a router might choose not to > trust the CM's aggregation (labelling) and then should make its > independent decisions based on its independent access to information > in a database.) > > In the meantime, in the absence of such a database, the CM aggregates > FLOWs into MACROFLOWs based on the destination host of the FLOWs. > > Dorothy Curtis > MIT/LCS > > Date: Thu, 06 Apr 2000 16:34:28 -0400 > From: John Border > To: hari@lcs.mit.edu, sseshan@us.ibm.com > CC: ecm@aciri.org > Subject: CM MACROFLOWs versus DiffServ and MPLS > References: <199911300040.QAA29976@daffy.ee.lbl.gov> > > > The Congestion Manager draft suggests that FLOWs between the same two end > points which experience identical congestion behavour in the Internet SHOULD > belong to the same MACROFLOW. This makes sense. But, with DiffServ and MPLS > (and perhaps other mechanisms) now providing the means for FLOWs between two > hosts to take different paths, it appears difficult for a host to know which > FLOWs to group together into MACROFLOWs. Having the host set its own initial > DSCP would help but would still not completely address the issue. The latest > (-02) Congestion Manager draft basically defers this issue as future work. > But, the concept of a MACROFLOW seems fundamental to the CM idea so I was > wondering if you (or someone else on the mailing list who has spent some time > thinking about this) could summarize the current thinking re this issue in a > couple of paragraphs... > > > John Border > Hughes Network Systems > From owner-ecm@wyvern.aciri.org Tue Apr 11 18:43:56 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 SAA23452 for ; Tue, 11 Apr 2000 18:43:56 -0400 (EDT) Received: (from majordomo@localhost) by wyvern.aciri.org (8.9.3/8.9.3) id PAA34664 for ecm-outgoing; Tue, 11 Apr 2000 15:41:36 -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 breeze.lcs.mit.edu (breeze.lcs.mit.edu [18.31.0.83]) by wyvern.aciri.org (8.9.3/8.9.3) with ESMTP id PAA34659 for ; Tue, 11 Apr 2000 15:41:34 -0700 (PDT) (envelope-from hari@breeze.lcs.mit.edu) Received: from breeze.lcs.mit.edu (hari@localhost [127.0.0.1]) by breeze.lcs.mit.edu (8.8.7/8.8.7) with ESMTP id SAA12024; Tue, 11 Apr 2000 18:41:17 -0400 Message-Id: <200004112241.SAA12024@breeze.lcs.mit.edu> X-Mailer: exmh version 2.0.2 Reply-To: Hari Balakrishnan X-url: http://wind.lcs.mit.edu/~hari/ To: jayanth cc: ecm@aciri.org Subject: Re: CM related In-reply-to: Your message of "Tue, 29 Feb 2000 11:36:24 PST" <20000229113624.A14772@yahoo-inc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Apr 2000 18:41:17 -0400 From: Hari Balakrishnan Sender: owner-ecm@aciri.org Precedence: bulk On Tue, 29 Feb 2000 11:36:24 PST, you wrote: > how would the CM based protocols perform if the receiver > feedback is zero ? If one were to deploy a CM based approach > but cannot expect any feeback from the receiver, in terms of > response to CM probes,etc could the CM extract more information per flow > then the existing TCP stack. > > thanks, > jayanth Jayanth, Catching up on old old mail... To do (feedback-based) congestion control, you need some form of feedback. :) In the absence of changes to receiver operating systems or protocol stacks, this feedback needs to come from applications. The reason you need feedback for congestion management is to figure out whether in the past round-trip, your transmissions reached successfully or encountered congestion. The comparison to an existing TCP stack that you make isn't clear to me. If you're running TCPs over CM, the corresponding ACK feedback is all that's needed for the CM to work. The advantage the CM provides in this case is two-fold: 1. Treats the ensemble of TCPs (in the same macroflow) as one congestion group 2. Allows the sending app or system admin to decide how to partition the "pipe" amongst the connections in the ensemble. The CM (according to the IETF draft) doesn't send any explicit probe messages. Does this clarify things? Hari From owner-ecm@wyvern.aciri.org Wed Apr 12 15:30:38 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 PAA01695 for ; Wed, 12 Apr 2000 15:30:37 -0400 (EDT) Received: (from majordomo@localhost) by wyvern.aciri.org (8.9.3/8.9.3) id MAA41174 for ecm-outgoing; Wed, 12 Apr 2000 12:26: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 sabre.sjf.novell.com (sabre.sjf.novell.com [130.57.86.42]) by wyvern.aciri.org (8.9.3/8.9.3) with ESMTP id MAA41169 for ; Wed, 12 Apr 2000 12:26:40 -0700 (PDT) (envelope-from mahdavi@sabre.sjf.novell.com) Received: (from mahdavi@localhost) by sabre.sjf.novell.com (8.9.3/8.9.3) id MAA04084; Wed, 12 Apr 2000 12:26:39 -0700 Reply-To: mahdavi@novell.com To: ecm@aciri.org Subject: Re: CM MACROFLOWs versus DiffServ and MPLS References: <200004111946.PAA11544@breeze.lcs.mit.edu> From: Jamshid Mahdavi Date: 12 Apr 2000 12:26:39 -0700 In-Reply-To: Hari Balakrishnan's message of "Tue, 11 Apr 2000 15:46:31 -0400" Message-ID: Lines: 38 X-Mailer: Gnus v5.7/Emacs 20.4 Sender: owner-ecm@aciri.org Precedence: bulk An interesting point to note is that a single TCP connection is subject to all the same effects. There could be split routing in the network; a diff-serv classifier could choose to mark only those packets fitting in a certain profile; etc. I don't think we know how to deal with this problem for a single TCP connection. We mostly just hope that there isn't split routing, and if there is, we blame the network for the problem, not TCP. I suppose that one could argue that having the network decide to give different classifications to separate TCP connections which are part of the same application is similarly broken. (Unless the application requests it, of course). --Jamshid Hari Balakrishnan writes: > John, > > The fundamental problem behind the issue you bring up is a relatively hard > research question. What we are looking for is a way by which the sender (with > feedback from the receiver) can correctly infer which flows share a common > path. What makes this hard is that we would like to do this: > (i) without any additional traffic, > (ii) without really modifying the timing of packet transmissions (e.g., by > picking packet times so the source looks Poisson), since that may violate > congestion control and/or lead to degraded performance, > (iii) fast. Within a few RTTs, > (iv) without false negatives. I.e., two flows shouldn't be deemed in the same > macroflow if they do not share the same congestion points. > > Devising an end-to-end inference scheme that meets all of these conditions is > an open research problem at this time. However, I feel comfortable thinking > that these problems will be solved in some practical (probably non-ideal) way > before Diffserv gets widely deployed. > ...