Subject: Intserv MIB comments

From: "Michael W. Patrick" <[email-masked]>
Date: Thu, 19 Jun 1997 09:58:33 -0400

Fred,

A few comments/questions on <draft-ietf-intserv-mib-07.txt> draft:

1.  intSrvFlowOwner

    Don't most mib objects with an "other" choice make it the first one,
    (i.e. "other(1)") so that new choices can be added without "other"
    being in the middle?
    If the RFC hasn't been issued yet, I'd guess this qualifies as
    an editorial change.

2.  intSrvFlowDontAsk

    Can you give me a reference (e.g. a paper, or discussion archives,
    etc) that explain why this object is needed?  I don't know the
    history on this one.  At first glance, it looks more RSVP-specific
    that intserv-specific.

3.  inSrvFlowPoliced and intSrvFlowDiscard

    Has the group decided that this rather course level of stats is
    sufficient?  It seems to me that there  is still quite a bit
    of discussion on what to do with over-Tspec traffic, including
    at least the following choices:
        
        - dropping
        - delaying ("shaping")
        - forwarding best-effort
        - marking and forwarding  best-effort    

    A Truthvalue on drop/no-drop doesn't seem to be enough information.
    Does it make sense to indicate which of the above policies is in
    place for the flow, perhaps with a inSrvFlowPolicy choice with
    those choices (and "other(1)"!) ?

    Actually, I guess more detail is needed, because a GS flow might
    have its over-peak traffic dropped, but its under-peak and 
    over Tspec traffic delayed.  One could indicate this with
    separate intSrvOverPeakPolicy and intSrvOverTrafficPolicy objects.

4.  Policy action counts
    
    Given different policy actions for over-peak and over-traffic packets
    (i.e. over the Tspec token bucket), does it make sense to
    separately count those policy actions? This would be separate
    intSrvFlowOverPeakDropped, intSrvFlowOverTrafficDelayed, etc counts.  

    Wouldn't this information on a per-flow basis be useful to
    operators and especially to statistic-based admission policies?
    
5.  intSrvFlowStats

    Perhaps the per-flow per-reason policing counts could be in an optional
    intSrvFlowStats table, where only the sum of the policed actions
    are kept in intSrvFlowTable?

6.  Packet/Byte counts per flow

    Wouldn't it be useful to give straight byte and packet counts per
    flow?  A stats-based admission policy needs this, and as a network
    operator, I would certainly want the level of traffic
    on each flow, perhaps for billing purposes.
    This could go in the optional intSrvFlowStats table.

7.  Service Failure Stats
    
    Shouldn't there be a count of "service failures" of some kind, when
    service guarantees were not met?  An example would be a packet
    delayed over a maximum per-hop delay guarantee. A mib object 
    could report a packet delay threshold (in microseconds) calculated
    from Rspec (GS) or Tspec (CL), and then a count of
    packets exceeding that delay.  The ratio of excess-delayed to
    forwarded packets per flow gives the service level failure rate.
    A similar "service failure" stat would be the duration of time 
    (say, in seconds) during which the flow was backlogged and
    received less than its intSrvFlowRate in bandwidth.
    A third service failure count would be the number of packets
    dropped from the flow due to insufficient buffers.
    Again, all of these could be optional in an intSrvFlowStats table.

    Feedback we've had from customers indicate they desire this level
    of reporting from their network provider.
    Furthermore, all of these service failure counts would provide feedback to
    a statistically-sharing service provider to reduce the level
    of sharing.

Is the last call over? If so, then does it perhaps make sense for me
to propose an optional intSrvFlowStats table in a separate draft?
If people think the various stats proposed above are useful, I think
Intserv should standardize a MIB for them before each vendor goes off
and implements a private MIB for the stats.

Regards,
-mike
------------------------------------------------------------------------
Michael W. Patrick  Motorola ISG, Cable Data Products  20 Cabot Rd, M4-30
[email-masked]  (508) 261-5707               Mansfield MA 02048