Re: RDMA MIB?

Caitlin Bestler <[email protected]>
Newsgroups gmane.ietf.rddp
Message-ID <[email protected]>
On Jan 21, 2004, at 6:18 PM, Jim Pinkerton wrote:

>  
>
> From Mike Krause’s comments on the security draft:
>
>  
>
> > (24) 7.5.3 It is not clear to me that a RDMA MIB is required.  One 
> can
>
> > understand whether a LLP or a physical interface are making forward
>
> > progress through the existing MIBs.  Providing additional statistics 
> isn't
>
> > really of value as one knows the connections / streams and layer 2 
> are
>
> > making forward progress.  After that, one checks to see if the ULP is
>
> > making forward progress and therefore we have a complete picture 
> without
>
> > requiring yet another MIB to implement / manage.
>
> >
>
>  
>
>  
>
> Anyone else have comments?  Here’s what’s currently in the security 
> draft. I can
> rewrite it if appropriate. One possibility would be to add an 
> additional example
> of monitoring the existing transport stream with the enhanced MIBs 
> that allow
> monitoring a specific flow. Traditional MIBs don’t enable monitoring 
> of a specific
> flow though, so would not necessarily give insight into resource 
> starvation.
>
>  

There is a need for *some* method of monitoring forward progress, but I 
agree
with Mike that any applicable existing monitors would solve the problem.
Forward LLP progress is very correlated with forward RDMAP/DDP progress.

However, I don't believe we should imply that LLP statistics SHOULD be
gathered on these connections. In many environments it might be easier
to monitor forward progress at the DDP layer. We should not mandate that
the tracking occur at the lower layer, even though inertia will very
heavily favor doing it there.

The important thing is that we not require implementations to make MIB
tallies at *both* the LLP and iWarp layers.


-- 
Caitlin Bestler - [email protected] - http://asomi.com/
http://asomi.com/CaitlinBestlerPublicPgpKey.html
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.