RE: Ecosystems cost of additional specs (RE: Please re ad - proposed WG termination)

At 12:46 PM 9/2/2005, Dror Goldenberg wrote:

>
>
>  From: Harald Tveit Alvestrand 
> [<mailto:[email protected]>mailto:[email protected]]
>  Sent: Friday, September 02, 2005 10:42 AM
>
>
>The important questions to ask are, I think:
>
>- What will be the cost of implementing be to willing participants who 
>want to implement the extension?
>- What will the cost of implementing be to participants who do not wish to 
>implement the extension?
>
>If the first one is "high", that may not be a show-stopper; people who 
>want to try are welcome to, and they hurt nobody but themselves.
>
>[dg] I think that the cost is not that high. We're looking at implementing 
>it. The two major issues are the ones that people already identified: the 
>per neighbor MTU and the supporting the large frame buffers that are 
>larger than a 4KB page. Both are OS specific issues (we're specifically 
>looking at Linux). The large frame buffer, is a problem that exists today 
>even for Ethernet jumbograms.
>
>
>
>If the second one is "high", or there's a risk that it's high, we shold 
>be  VERY careful, and perhaps run official experiments before releasing it 
>on the standards track - this is traditionally done, for instance, on 
>extensions to TCP like ECN, or on extensions to routing protocols.
>
>[dg] There isn't any cost to people that don't want to implement it. 
>ipoib-ud and ipoib-cm are supposed to fully interoperate. They will 
>obviously downgrade to ipoib-ud. So, if one doesn't want to implement  it, 
>fine, nothing really happens, ipoib-ud will always work.
>
>
>
>I can see the argument that for a particular implementation, the cost of 
>implementing IPoIB-CM with a large MTU may be high - but since it seems a 
>facility that's relatively easy to negotiate for, I don't quite see that 
>it has a large ecosystem impact on IPoIB-UD implementations.
>If it's a Bad Idea, it may get published, and wither away like so many 
>other "proposed standards" that nobody cares about any more.
>
>OTOH, if it's really a Good Idea, the choice is not really between a
>standard and no IPoIB-CM; it's between a standard and multiple, possibly 
>incompatible IPoIB-CM variants. Nobody can prevent people from 
>implementing from the current draft, assigning their own service-ID(?) and 
>just shipping.
>
>[dg] Standards are always better than interoperability issues. And, most 
>of the ipoib-cm is done so far, so I really see value in completing the 
>standardization work. There is a really good chance that many systems can 
>benefit from it.

Somewhat an aside, but it is ironic that standard APIs are often ignored / 
deemed "crap" by some even if many systems can benefit from them yet this 
spec which is likely to be implemented by a single OS and used only in 
perhaps a subset of deployments is deemed worthy. Apologies for the tangent.

Mike

_______________________________________________
IPoverIB mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ipoverib