Re: RDMA MIB?
Michael Krause <[email protected]>
| Newsgroups | gmane.ietf.rddp |
|---|---|
| Message-ID | <[email protected]> |
At 11:03 PM 1/21/2004 -0600, Caitlin Bestler wrote: >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. I agree that inertia will favor using the existing methods as many iWARP implementations may expose their LLP protocol off-load interface directly thus would prefer a single method be provided to track forward progress. My preference though, remains not spending resources on developing an iWARP MIB unless someone can demonstrate strong value for consumers or that the LLP methods are significantly deficient. I do not believe there is a strong case being driven from a security aspect. >The important thing is that we not require implementations to make MIB >tallies at *both* the LLP and iWarp layers. Strongly agree that this would be impractical due to very low cost / value. Mike >-- >Caitlin Bestler - [email protected] - http://asomi.com/ >http://asomi.com/CaitlinBestlerPublicPgpKey.html > > >_______________________________________________ >rddp mailing list >[email protected] >https://www1.ietf.org/mailman/listinfo/rddp