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

---

From: Fred Baker <[email-masked]>
Date: Fri, 20 Jun 1997 22:02:01 -0700

I didn't see the posting to the mailer, so I'm resending. I'd like working
group comments

>    If the RFC hasn't been issued yet, I'd guess this qualifies as

I'm unaware of a convention in this area, but if we're making other changes
I suppose we could pick it up.

>    history on this one.  At first glance, it looks more RSVP-specific

    intSrvFlowDontAsk OBJECT-TYPE
        SYNTAX      TimeInterval
        MAX-ACCESS  read-create
        STATUS      current
        DESCRIPTION
           "A period of time, measured in hundredths of  a
           second,  during  which  the  agent is precluded
           from sending a newFlow  notification  for  this
           conversation.

           If   an    authorizing    application    leaves
           intSrvFlowStatus  in a state other than neither
           consider the flow active for admission or queu-
           ing  purposes,  or  re-request authorization to
           install it, until the indicated amount of  time
           has elapsed."
       ::= { intSrvFlowEntry 19 }

I suppose if there is opposition we could pull this out. Observing the
rapid state of progress in IPC, I sketched in a way to do the policy thing
using RSVP, and put the interlock here as the thing being reported is
otherwise described here. My observation remains that there are no changes
to IPC resulting from community feedback, and no clear agenda for reaching
a conclusion.

>    Has the group decided that this rather coarse level of stats is
>    sufficient?

In all honesty, the working group has said very little on the subject of
the MIB; eyes rapidly glaze over. Most of the comments that I have had on
the MIB come from a very small set of people.

>    It seems to me that there  is still quite a bit

One could send text?

>    separately count those policy actions?

Would one not first have to make this distinction? My understanding of the
specifications did not call for automatic dropping of all over-rate
traffic, but that it be treated as Best Effort. In this way, we have not
broken the use of the Integrated Services Architecture for things that are
not video/audio.

>    This would be separate

Perhaps. I suppose we could add a counter for traffic remanded to best
effort service.

>    are kept in intSrvFlowTable?

What else would you want in the table? This sounds like lily-guilding, IMHO.

>    This could go in the optional intSrvFlowStats table.

I suppose that might be nice, but I don't know that all implementations are
automagically going to look at all packets...

>    delayed over a maximum per-hop delay guarantee.

I'm not sure I would know how to implement making this counter count, in a
production router.

>    A mib object

Doesn't this kind of assume that we have this problem occur? I don't see
any reason to believe that it would occur.

>Is the last call over?

Well, the working group last call closed a couple of months ago, and the
IETF last call is probably formally over. but if there are substantive
comments and the working group replies saying that these counters are
essential, we could pick them up.

>If so, then does it perhaps make sense for me

Yes, I think so. Sending text describing the objects you want would, I
think, be sufficient. The principal value of having it in a separate table
seems, to me, to be for making the objects optional, though. Explain why
they should not be in the flow entry?

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Today's vocabulary enhancement:
	"yuppie food coupons" = twenty dollar bills from an ATM

---

From: Fred Baker <[email-masked]>
Date: Fri, 20 Jun 1997 22:02:01 -0700

One could send text?