<div dir="ltr">Brian,<div><br></div><div>I took this as an opportunity to re-read your draft, and I have another example for section 3, well-managed wide area networks run by service providers for private enterprise business services such as layer 2 (Ethernet, etc.) point-to-point pseudowires, multipoint layer 2 Ethernet VPNs using VPLS or EVPN, and layer 3 IP VPNs. These are generally characterized by service level agreements for availability and packet loss. These are different from your #9 in that they mostly run over MPLS infrastructures and the requirements for these services are well-defined by the IETF.</div><div><br></div><div>Cheers,</div><div>Andy</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 29, 2019 at 1:37 AM Brian E Carpenter <<a href="mailto:brian.e.carpenter@gmail.com">brian.e.carpenter@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 29-Mar-19 11:33, Karl Auerbach wrote:<br>
> <br>
> On 3/27/19 7:16 PM, Jack Haverty wrote:<br>
> <br>
>> The "packet driver" standardization may have made it easier for all<br>
>> those people to write their TCP stacks -- but there was no such<br>
>> standardization at the next level - the APIs that allowed an app to use<br>
>> those stacks.  So we needed different code for each TCP stack.<br>
> <br>
> The Winsock API evolved on the top side of many of the TCP stacks. <br>
> Winsock was a distant relative of the Unix socket API (and when I say <br>
> "distant" I mean "they could almost see one another on a clear day with <br>
> a good telescope").  If I remember correctly there was a vendor <br>
> consortium to work on making sure that Winsock was clear and solid.  I <br>
> do remember running some Winsock interoperability bake-offs.<br>
<br>
Yes, all of that. But it remains a daily problem that Winsock2 is<br>
incompatible with the POSIX socket API, and there are some subtle<br>
and not-so-subtle discrepancies that make software portability a<br>
real problem to this day, when you are trying to do anything<br>
even slightly off the beaten track.<br>
<br>
>> I wonder if that is where the boundary starts between interoperability<br>
>> and walled gardens<br>
<br>
No, I don't think so, not any more. But as far as I'm concerned that<br>
isn't a history topic... Oh, all right, I mean:<br>
<a href="https://tools.ietf.org/html/draft-carpenter-limited-domains" rel="noreferrer" target="_blank">https://tools.ietf.org/html/draft-carpenter-limited-domains</a><br>
<br>
   Brian<br>
<br>
> <br>
> At the Interop shows, especially in the earlier days, we (the team that <br>
> built and ran the show net) really beat up on vendors that were not <br>
> interoperable.  I remember at least one case where we simply unplugged a <br>
> router/switch vendor because they were not playing nice.<br>
> <br>
> We always pre-built and pre-tested the main show network (45.x.x.x/8) in <br>
> a warehouse a couple of months before the show.  That way we had <br>
> everything relatively solid before we loaded up the trucks (and we <br>
> filled a lot of trucks - I remember once we filled 43 large semitrailers <br>
> - and that was just for our own gear, not the vendors'.)<br>
> <br>
> And wow, did we ever find some pathological non-interoperation.  But <br>
> sometimes the cause was relatively innocent - as one instance having to <br>
> do with a difference of interpretation regarding the forwarding of IP <br>
> multicast packets between Cisco and Wellfleet routers that ended up <br>
> causing us an infinite ethernet frame loop.  And once our FDDI expert - <br>
> Merike Kaeo - found a specification flaw in FDDI physical layer stuff: <br>
> The various vendors came up with a fix on the spot and were blasting new <br>
> firmware into PROMs in their hotel rooms.<br>
> <br>
> <br>
>   - i.e., where people take advantage of the "lower"<br>
>> uniformity brought by some standard (whether in spec or in code), but<br>
>> fail to coordinate standardization at the level "above" them, where they<br>
>> present their services to the next guy up.  By maintaining uniqueness,<br>
>> they hope their walled garden will be the one to thrive.<br>
> <br>
> I recently had someone confirm a widely held belief that Sun <br>
> Microsystems had tuned the CSMA/CD timers on their Ethernet interfaces <br>
> to have a winning bias against Ethernet machines that adhered to the <br>
> IEEE/DIX ethernet timer values.  Those of us who tended to work with <br>
> networked PC platforms were well aware of the effect of putting a Sun <br>
> onto the same Ethernet: what had worked before stopped working, but the <br>
> Suns all chatted among themselves quite happily.<br>
> <br>
> And FTP Software used to put its license key information in the part of <br>
> Ethernet frames between the end of an ARP and the end of the data of the <br>
> Ethernet frame.  That caused a lot of strange side effects.  (One can <br>
> still send a lot of IP stacks into death spirals by putting an IPv4/v6 <br>
> packet into an Ethernet frame that is larger than the minimum needed to <br>
> hold the IP packet - a lot of deployed code still incorrectly uses the <br>
> received frame size to impute the length of the IP packet rather than <br>
> looking at the IP header.)<br>
> <br>
> And FTP software also realized that with IP fragmentation the receiver <br>
> really does not know how big a buffer will ultimately be required until <br>
> the last fragment arrives.  So they altered their IP stack to send the <br>
> last fragment first.  That had the effect of causing all of their <br>
> competitor Netmanage stacks to crash when they got a last-fragement-first.<br>
> <br>
>               --karl--<br>
> _______<br>
> internet-history mailing list<br>
> <a href="mailto:internet-history@postel.org" target="_blank">internet-history@postel.org</a><br>
> <a href="http://mailman.postel.org/mailman/listinfo/internet-history" rel="noreferrer" target="_blank">http://mailman.postel.org/mailman/listinfo/internet-history</a><br>
> Contact <a href="mailto:list-owner@postel.org" target="_blank">list-owner@postel.org</a> for assistance.<br>
> <br>
<br>
<br>
_______<br>
internet-history mailing list<br>
<a href="mailto:internet-history@postel.org" target="_blank">internet-history@postel.org</a><br>
<a href="http://mailman.postel.org/mailman/listinfo/internet-history" rel="noreferrer" target="_blank">http://mailman.postel.org/mailman/listinfo/internet-history</a><br>
Contact <a href="mailto:list-owner@postel.org" target="_blank">list-owner@postel.org</a> for assistance.<br>
</blockquote></div>