From owner-rtfm@auckland.ac.nz Thu Jan 24 16:50:35 2002 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07102 for ; Thu, 24 Jan 2002 16:50:33 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id JAA17959; Fri, 25 Jan 2002 09:20:29 +1300 (NZDT) Received: from n.browlee5.itss.auckland.ac.nz (n.brownlee5.itss.auckland.ac.nz [130.216.4.79]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id JAA17920; Fri, 25 Jan 2002 09:20:23 +1300 (NZDT) From: Nevil Brownlee To: David Hausheer Cc: rtfm@auckland.ac.nz Subject: Re: NeTraMet & ECN In-Reply-To: <3C4C439E.7D335CF3@tik.ee.ethz.ch> Message-ID: Date: Fri, 25 Jan 2002 09:21:31 +1300 (New Zealand Daylight Time) Priority: NORMAL X-Mailer: Simeon for Win32 Version 4.1.4 Build (40) X-Authentication: IMSP MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hello David: > Does - and if yes - how does NeTraMet provide information about ECN > (Explicit Congestion Notification) > a) in the IP Header > b) in the TCP Header > now or in future versions? Is there anything planned? To answer the direst question, it doesn't now, and I hadn't thought about it. However, now that you've raised it, I think it's a good idea, and it certainly isn't hard to do. As I recollect (I'll have to look at Sally Floyd's drafts again) the bottom 2 bits of the original IPv4 TOS bute were reserved for IP ECN - which I think is your (a) above. If you want to try this, you can easily modify NeTraMet to do it. The relevant code is in src/meter/flowhash.c; search for statements containing 'b->DSCodePoint =' . These get the value for the DSCodePoint attribute. You'll see that they shift the TOS byte 2 bytes to the right, discarding the ECN bits. Just remove the >> 2 and recompile NeTraMet, then you can use DSCodePoint & 3 in an SRL ruleset to test the ECN bits. Longer term, ECN is clearly a packet-based attribute, like DSCodePoint. We just need to decide what name we use for an ECN attribute - 'ECN' seems a bit short. And what exactly do you mean by (b) above? Is there a draft proposing bits it the TCP header for ECN? If so, maybe we need an ECN attribute containing bits for IP and TCP, rather than having separate ECN_IP and ECN_TCP ?? What would you suggest? Cheers, Nevil +---------------------------------------------------------------------+ | Nevil Brownlee Director, Technology Development | | Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | | FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand | +---------------------------------------------------------------------P From owner-rtfm@auckland.ac.nz Fri Jan 25 09:04:44 2002 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.191.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02981 for ; Fri, 25 Jan 2002 09:04:43 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id CAA09143; Sat, 26 Jan 2002 02:01:52 +1300 (NZDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with SMTP id CAA09135; Sat, 26 Jan 2002 02:01:49 +1300 (NZDT) Received: from brazil.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 25 Jan 2002 13:01:45 +0000 Date: Fri, 25 Jan 2002 13:06:25 +0000 (GMT) From: Marcelo Pias To: Nevil Brownlee cc: David Hausheer , rtfm@auckland.ac.nz Subject: Re: NeTraMet & ECN In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Hello Nevil & David, We at UCL and BT Labs have implemented support for ECN within NeTraMet sometime ago (1999). The implementation was based on the RFC 2481 (experimental) back to Jan/1999. However, we didn't revise it according to the new RFC 3168 (standards track) Sep/2001. In line with the RFC 2481, we added 4 new attributes to the RTFM MIB which would correspond to counters for the two bits in IP header and other two in the TCP header. They are: ------------------------------------------------------------------- toECTPDUs(95), -- ECN: Source-to-Dest ECT pkts toCEPDUs(96), -- ECN: Source-to-Dest CE pkts toCWRPDUs(97), -- ECN: Source-to-Dest CWR pkts toECEPDUs(98), -- ECN: Source-to-Dest ECE pkts fromECTPDUs(99), -- ECN: Dest-to-Source ECT pkts fromCEPDUs(100), -- ECN: Dest-to-Source CE pkts fromCWRPDUs(101), -- ECN: Dest-to-Source CWR pkts fromECEPDUs(102) -- ECN: Dest-to-Source ECE pkts ------------------------------------------------------------------ However, it turned out that for our specific use of the ECN mechanism, we just needed the IP header bits (ECT&CE). In addition, we've started implementing a token bucket (R,B) scheme to configure the rate of CE packets seen in order to tell levels of congestion. This is still being implemented. Very slow, I have to say. Nevil --> these attributes were my proposal to be included in your draft 'implementing new attributes' (http://www2.auckland.ac.nz/net/Internet/rtfm/) back to that our effort to create the RTFM2 WG within the IETF on 2000. My suggestion would be to support ECN using the codepoints as defined in the RFC 3168 (standards track). There will be difference in the attribute names (now there're four codepoints: NOT-ECT, ECT(1), ECT(0), CE) compared to we've done. I don't see now a big need for counters of the TCP header bits. This is our experience with ECN/RTFM so far. It'd be nice to hear any comments or other experiences with ECN and the RTFM meter. Cheers. Marcelo On Fri, 25 Jan 2002, Nevil Brownlee wrote: > > Hello David: > > > Does - and if yes - how does NeTraMet provide information about ECN > > (Explicit Congestion Notification) > > a) in the IP Header > > b) in the TCP Header > > now or in future versions? Is there anything planned? > > To answer the direst question, it doesn't now, and I hadn't thought > about it. > > However, now that you've raised it, I think it's a good idea, and it > certainly isn't hard to do. As I recollect (I'll have to look at Sally > Floyd's drafts again) the bottom 2 bits of the original IPv4 TOS bute > were reserved for IP ECN - which I think is your (a) above. If you > want to try this, you can easily modify NeTraMet to do it. The > relevant code is in src/meter/flowhash.c; search for statements > containing 'b->DSCodePoint =' . These get the value for the > DSCodePoint attribute. You'll see that they shift the TOS byte 2 bytes > to the right, discarding the ECN bits. Just remove the >> 2 and > recompile NeTraMet, then you can use DSCodePoint & 3 in an SRL ruleset > to test the ECN bits. > > Longer term, ECN is clearly a packet-based attribute, like DSCodePoint. > We just need to decide what name we use for an ECN attribute - 'ECN' > seems a bit short. And what exactly do you mean by (b) above? Is > there a draft proposing bits it the TCP header for ECN? If so, maybe > we need an ECN attribute containing bits for IP and TCP, rather than > having separate ECN_IP and ECN_TCP ?? What would you suggest? > > Cheers, Nevil > > +---------------------------------------------------------------------+ > | Nevil Brownlee Director, Technology Development | > | Phone: +64 9 373 7599 x8941 ITSS, The University of Auckland | > | FAX: +64 9 373 7021 Private Bag 92019, Auckland, New Zealand | > +---------------------------------------------------------------------P > > ---------------------------------------------------------- www.cs.ucl.ac.uk/staff/m.pias/ From owner-rtfm@auckland.ac.nz Fri Jan 25 14:27:31 2002 Received: from mailhost.auckland.ac.nz (mailhost.auckland.ac.nz [130.216.1.4]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11919 for ; Fri, 25 Jan 2002 14:27:29 -0500 (EST) Received: (from majordom@localhost) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) id HAA03217; Sat, 26 Jan 2002 07:01:48 +1300 (NZDT) Received: from stimpy.networkrobots.com ([65.89.31.210]) by mailhost.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id HAA03211; Sat, 26 Jan 2002 07:01:45 +1300 (NZDT) Received: from vphalke (dhcp-2-172.networkrobots.com [192.168.2.172]) by stimpy.networkrobots.com (8.11.0/8.8.7) with SMTP id g0PI1iL18561; Fri, 25 Jan 2002 10:01:44 -0800 From: "Vidya Phalke" To: "'Nevil Brownlee'" , Subject: A new field for RTFM Date: Fri, 25 Jan 2002 10:01:19 -0800 Message-ID: <000401c1a5ca$4b5ce300$ac02a8c0@vphalke> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal X-Logged: Logged by stimpy.networkrobots.com as g0PI1iL18561 at Fri Jan 25 10:01:44 2002 Sender: owner-rtfm@auckland.ac.nz Precedence: bulk Content-Transfer-Encoding: 7bit Would it be a good idea to define a new attribute in the RTFM flowDataTable which holds a pointer. This will be to keep some info relevant to the flow that may be not applicable to all vendors. For example, here at Network Robots we intend to keep some NAT information on a per flow basis. I want to get people's opinion on this one. flowDataExtendedInfoPtr OBJECT-TYPE SYNTAX RowPointer MAX-ACCESS read-only STATUS current DESCRIPTION "This attribute provides an indirection to another table that may contain some more static details about the flow" ::= { flowDataEntry 42 } Vidya Phalke, PhD Senior NMS Engineer http://www.networkrobots.com