From mailnull@www1.ietf.org Sun Feb 23 21:21:02 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17998 for ; Sun, 23 Feb 2003 21:21:02 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1O2TLM07911 for iporpr-archive@odin.ietf.org; Sun, 23 Feb 2003 21:29:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O2TLp07908 for ; Sun, 23 Feb 2003 21:29:21 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17993 for ; Sun, 23 Feb 2003 21:20:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O2T7p07877; Sun, 23 Feb 2003 21:29:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O2R8p07815 for ; Sun, 23 Feb 2003 21:27:08 -0500 Received: from acsn05.bu.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17936 for ; Sun, 23 Feb 2003 21:18:18 -0500 (EST) Received: from anthem (dip12-ppp-199.bu.edu [168.122.12.199]) by acsn05.bu.edu ((8.9.3.buoit.v1.1.RewriteVBS.ACS)/BU_Server-1.3) with SMTP id VAA129660 for ; Sun, 23 Feb 2003 21:20:54 -0500 Message-ID: <00f501c2dbab$fa919290$c70c7aa8@anthem> From: "Anthem ChenMin" To: Date: Sun, 23 Feb 2003 21:25:19 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F2_01C2DB82.10EC0590" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [IPORPR] A question on RPR's service policy Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-BeenThere: iporpr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Resilient Packet Rings List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_00F2_01C2DB82.10EC0590 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSBoYXZlIGEgcXVlc3Rpb24uIElmIHdlIGFuYWx5emUgdGhlIFJQUiBpbiBmbHVpZCBtb2RlbCwg d2hhdCBpcyB0aGUgc2VydmljZSBwb2xpY3k/IEZJRk8/IE9yIEdlbmVyYWxpemVkIHByb2Nlc3Mg c2hhcmluZz8NCklmIHRoYXQgaXMgRklGTywgc2VlbXMgbGlrZSBpZiB0aGVyZSBhcmUgZGlmZmVy ZW50IGNsYXNzIG9mIHNhbWUgcHJpb3JpdHkgcGFja2V0cywgYWZ0ZXIgcGFzc2luZyB0aHJvdWdo IG9uZSBub2RlLCBpdCB3b3VsZCBiZSBkaXN0b3J0ZWQgYWZ0ZXJ3YXJkcy4uDQogIEFueW9uZSBj YW4gaGVscCBtZT8NClRoYW5rcw0KDQpBbnRoZW0NCg== ------=_NextPart_000_00F2_01C2DB82.10EC0590 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNS41 MC40NTIyLjE4MDAiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5JIGhhdmUgYSBxdWVzdGlv bi4gSWYgd2UgYW5hbHl6ZSB0aGUgUlBSIGluIGZsdWlkIG1vZGVsLCB3aGF0IA0KaXMgdGhlIHNl cnZpY2UgcG9saWN5PyBGSUZPPyBPciBHZW5lcmFsaXplZCBwcm9jZXNzIHNoYXJpbmc/PC9GT05U PjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SWYgdGhhdCBpcyBGSUZPLCBzZWVtcyBsaWtlIGlm IHRoZXJlIGFyZSBkaWZmZXJlbnQgY2xhc3Mgb2YgDQpzYW1lIHByaW9yaXR5IHBhY2tldHMsIGFm dGVyIHBhc3NpbmcgdGhyb3VnaCBvbmUgbm9kZSwgaXQgd291bGQgYmUgZGlzdG9ydGVkIA0KYWZ0 ZXJ3YXJkcy4uPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+Jm5ic3A7IEFueW9uZSBj YW4gaGVscCBtZT88L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5UaGFua3M8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05U IHNpemU9Mj5BbnRoZW08L0ZPTlQ+PC9ESVY+PC9CT0RZPjwvSFRNTD4NCg== ------=_NextPart_000_00F2_01C2DB82.10EC0590-- _______________________________________________ IPORPR mailing list IPORPR@ietf.org https://www1.ietf.org/mailman/listinfo/iporpr From mailnull@www1.ietf.org Mon Feb 24 00:33:12 2003 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21782 for ; Mon, 24 Feb 2003 00:33:11 -0500 (EST) Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h1O5fXS19267 for iporpr-archive@odin.ietf.org; Mon, 24 Feb 2003 00:41:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O5fXp19264 for ; Mon, 24 Feb 2003 00:41:33 -0500 Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21772 for ; Mon, 24 Feb 2003 00:32:40 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O5bYp19062; Mon, 24 Feb 2003 00:37:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h1O5aPp18303 for ; Mon, 24 Feb 2003 00:36:25 -0500 Received: from acsn05.bu.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21653 for ; Mon, 24 Feb 2003 00:27:32 -0500 (EST) Received: from anthem (dip13-ppp-72.bu.edu [168.122.13.72]) by acsn05.bu.edu ((8.9.3.buoit.v1.1.RewriteVBS.ACS)/BU_Server-1.3) with SMTP id AAA47706; Mon, 24 Feb 2003 00:30:36 -0500 Message-ID: <000901c2dbc6$7af6fe10$480d7aa8@anthem> From: "Anthem ChenMin" To: "Anoop Ghanwani" Cc: References: <58BE468BAC66D511AFE6000347251A2D01A16AA8@MORPHEUS> Subject: Re: [IPORPR] A question on RPR's service policy Date: Mon, 24 Feb 2003 00:35:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id h1O5aPp18304 Sender: iporpr-admin@ietf.org Errors-To: iporpr-admin@ietf.org X-BeenThere: iporpr@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: IP over Resilient Packet Rings List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Thank you very much.And I understand the priority queuing you talked about. Maybe I need to explain my question this way: In the single queue, say, the passby low priority queue, there would be different fluid flow that are classified by Source-Destination. In that sense, in the single queue, when the server take different policy, the output of the server will be different. If we analyze it in a Packet Switch way, there would be no problem to regard it as FIFO model, but when we analyze it as a fluid model, is it more convenient to let flows(different sources and destinations) share the server? More explicitly, for example, X1 is the low priority flow from 1-->5 X2 is the low priority flow from 2-->4 Then when looking at 3rd node, it is easy to derive d/dt(X1+X2), but what is dX1/dt and dX2/dt? It depends on how the server serve the flow... Hope to get more idea from you.. Thanks Best Anthem ----- Original Message ----- From: "Anoop Ghanwani" To: "'Anthem ChenMin '" Sent: Sunday, February 23, 2003 10:21 PM Subject: RE: [IPORPR] A question on RPR's service policy > > This question is probably more appropriate for the IEEE 802.17 > list. See http://www.ieee802.org/17. > > To answer your question, the service discipline at a node > depends on the transit queue architecture. It's class-based > priority scheduling, rather than either FIFO or GPS. With > a single transit queue, the service discipline at node is: > > - Transit queue > - Insert Class A > - Insert Class B > - Insert Class C > > With dual transit buffer, the priority changes depending > on the occupancy of the secondary transit queue. > (Class A is transported in primary transit queue > and B and C in secondary transit queue.) > > If secondary transit queue is < STQlowthresh > > - Transit primary > - Insert Class A > - Insert Class B > - Insert Class C > - Transit secondary > > If secondary transit queue is > STQlowthresh, but < STQFullthresh > > - Transit primary > - Insert Class A > - Insert Class B > - Transit secondary > - Insert Class C > (A node doesn't get to insert Class C traffic in this mode.) > > If secondary transit queue = STQfullthresh > > - Transit primary > - Transit secondary > - Insert Class A > - Insert Class B > - Insert Class C > (A node doesn't get to insert any traffic in this mode.) > > I am not 100% sure about the scheduling rules for the > 2 transit queue case but the above is what I think it is. > One thing to note is that once a frame is admitted by the > MAC, the scheduling discipline at every node guarantees > that it will not be dropped due to congestion. Also > there is no reordering of frames within a class. > > Hope this helps. > > -Anoop > > -----Original Message----- > From: Anthem ChenMin > To: iporpr@ietf.org > Sent: 2/23/03 6:25 PM > Subject: [IPORPR] A question on RPR's service policy > > I have a question. If we analyze the RPR in fluid model, what is the > service policy? FIFO? Or Generalized process sharing? > If that is FIFO, seems like if there are different class of same > priority packets, after passing through one node, it would be distorted > afterwards.. > Anyone can help me? > Thanks > > Anthem > _______________________________________________ IPORPR mailing list IPORPR@ietf.org https://www1.ietf.org/mailman/listinfo/iporpr