Subject: Re: NeTraMet & ECN

From: Nevil Brownlee <[email-masked]>
Date: Fri, 25 Jan 2002 09:21:31 +1300 (New Zealand Daylight Time)

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: Marcelo Pias <[email-masked]>
Date: Fri, 25 Jan 2002 13:06:25 +0000 (GMT)

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

> having separate ECN_IP and ECN_TCP ??  What would you suggest?

----------------------------------------------------------
www.cs.ucl.ac.uk/staff/m.pias/

---

From: "Vidya Phalke" <[email-masked]>
Date: Fri, 25 Jan 2002 10:01:19 -0800

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