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

From: Dror Goldenberg <[email-masked]>
Date: Fri, 2 Sep 2005 22:46:15 +0300

From: Harald Tveit Alvestrand [ mailto:[email-masked]
<mailto:[email-masked]> ]
 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.

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

---

From: Michael Krause <[email-masked]>
Date: Fri, 02 Sep 2005 15:45:30 -0700

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

>
>
>  From: Harald Tveit Alvestrand 
> [<mailto:[email-masked]>mailto:[email-masked]]
>- What will be the cost of implementing be to willing participants who 
>want 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.
>
>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 
>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.
>
>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 

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sat, 03 Sep 2005 09:49:06 +0200

--On 2. september 2005 15:45 -0700 Michael Krause <[email-masked]> wrote:

> 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.

the IETF tradition is to not do APIs, mostly for 2 reasons:

- traditionally, the IETF has not had competence in them
- they can detract from the focus on "what's going to go on the wire"

The scary examples (to IETF-interoperability-heads) of non-IETF specs 
include MPI, which specified an API and *not* a wire protocol - resulting 
in portable programs, but not interoperability between different 
implementations. May have been a rational decision in its context, but 
definitely different to how IETFers think about specs.

A scary example of IETF getting it wrong (to my mind) is GSS-API, which 
specifies a protocol by specifying procedure calls - getting the protocol 
right is then QUITE not-easy....

I haven't heard them called "crap" in the IETF, but I've definitely heard 
them called "second to the protocols" and "please, let someone else worry 
about it".

                              Harald