From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 80E1C3B29D for ; Tue, 22 Mar 2022 14:33:35 -0400 (EDT) Received: by mail-wr1-x435.google.com with SMTP id v22so10760844wra.2 for ; Tue, 22 Mar 2022 11:33:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gseQ7T8n11ewdUMKnFw2QTl+msOeONGfvW84bVuuhX8=; b=OI7js8D18/aQGVTh2H5lHdOBhcu2reHxxoF8NgvEyKZuX8nDj+EVG+ALZfoj3r+oV/ XUMgONelcrpt3X8sLgNIwdyvkmxy1ICtHc6J6f4jemA/fCnrv+18LhnFk3/ciA2/dYBb ewUSte+/qVgu4zZ42euMGDOVyYTKl7xi9UZYEALKpIC9CqmxvOqFJ7s554pMGCqCfsQu YDOzeES1QzggOlfp3Q4Ny3EuvPEVJt3c42JxB+6XxUV1lCS7gthEkpLxxaaKhsLBSK/L jRIdDbNgDFYyf+5K8JvUglfc4eJPokoLPCw+1/Yd93e1zRCXYw62WyPtXW+N86kB5U/L HqdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gseQ7T8n11ewdUMKnFw2QTl+msOeONGfvW84bVuuhX8=; b=D46YZX54fNajMjPRvpRgYM461sUATun5CoETHuQLuMXc2obIKhnyQPnjsTosbvNk6H F9/chTQrXatG9mK4TX09a3Il91WzUt+yaHmFGq9jwfVcty6WcNO5iIJoqXvpqTd8EYqH C4s7TgAnEv53UygInaS9KsBbATjerWMWJBWBNGYnYjsmGyD7s1CU8HNpHedf1mCuaDgm u13W8eCmxMf4wCWbklnO9teFblgv6AbG1vs4jc6I6XU+zgndu3OkWRQCSZaQi1cIA7/F 9j2lHxe62opl77roRLwDTd9gf809pc5bvDwbtjI9YLxnCvWatCJq3qMN7OhQjWJh2pMP 5PEg== X-Gm-Message-State: AOAM5332pK4XTql9Ol2w37Ra0JNfo+PVQzkuhQ6tdtgVgcmocDxtg5nD P3rRqxJ2Zg6laFk/ZRykSM+AJQt5iLUt9pzFeAlQ/jgYdEw= X-Google-Smtp-Source: ABdhPJw2MuHemxtUE39rxZ92LdWMNL5f5k1FyPusSxTuB5LCa+37YOOQntLOA+kYAhcZ8lA1waoDzv5ylqYZWuRID2g= X-Received: by 2002:a5d:4204:0:b0:203:d794:93e0 with SMTP id n4-20020a5d4204000000b00203d79493e0mr23815947wrq.136.1647974014226; Tue, 22 Mar 2022 11:33:34 -0700 (PDT) MIME-Version: 1.0 References: <1A3B85A2-7978-4590-92A6-5B3077A3938C@delong.com> <72d82d3f-f05e-de88-5f09-d6b3afe8478c@necom830.hpcl.titech.ac.jp> <367728dd-02e8-cff1-ea9d-8f59e987fbe0@gmail.com> In-Reply-To: From: Vint Cerf Date: Tue, 22 Mar 2022 14:33:21 -0400 Message-ID: To: Dave Taht Cc: bloat , starlink@lists.bufferbloat.net Content-Type: multipart/alternative; boundary="000000000000b7f3fd05dad2d983" Subject: Re: [Bloat] [Starlink] Fwd: IPv6 "bloat" history X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2022 18:33:35 -0000 --000000000000b7f3fd05dad2d983 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable actually, as I recall, the IAB proposed the use of the CLNP *format *but not the protocol - since it already had a 128 bit address field and catered to connectionless functionality. It was assumed that the IAB was proposing to adopt the protocol and there was an immediate and negative reaction to that. POISED was the result. v On Tue, Mar 22, 2022 at 2:14 PM Dave Taht wrote: > some ipv6 history I didn't know. > > ---------- Forwarded message --------- > From: William Allen Simpson > Date: Tue, Mar 22, 2022 at 12:09 PM > Subject: Re: IPv6 "bloat" history > To: > > > Admitting to not having read every message in these threads, > but would like to highlight a bit of the history. > > IMnsHO, the otherwise useful history is missing a few steps. > > 1) The IAB selected ISO CLNP as the next version of IP. > > 2) The IETF got angry, disbanded, replaced, and renamed IAB. > > 3) On the Big-Internet list, my Practical Internet Protocol Extensions > (PIPE) was an early proposal, and I'd registered V6 with IANA. > > I was self-funding. PIPE was cognizant of the needs of ISPs and > deployment. > > 4) Lixia Zhang wrote me that Steve Deering was proposing something > similar, and urged us to pool our efforts. That became Simple > Internet Protocol (SIP). We used 64 bit addresses. We had a clear > path for migration, using the upper 32-bits for the ASN and the old > IPv4 address in the lower 32-bits. We had running code. > > 5) The IP Address Extension (IPAE) proposal had some overlapping > features, > and we asked them to merge with us. That added some complexity. > > 6) The Paul Francis (the originator of NAT) Polymorphic Internet Protoc= ol > (PIP) had some overlapping features, so we also asked them to merge > with us (July 1993). More complexity in the protocol header chainin= g. > > 7) The result was SIPP. We had 2 interoperable implementations: Naval > Research Labs, and KA9Q NOS (Phil Karn and me). There were others > well underway. > > 8) As noted by John Curran, there was a committee of "powers that be". > After IETF had strong consensus for SIPP, and we had running code, > the "powers that be" decided to throw all that away. > > 9) The old junk was added back into IPv6 by committee. > > There was also a mention that the Linux IP stack is fairly compact and > that IPv6 is somewhat smaller than the IPv4. That's because the Linux > stack was ported by Alan Cox from KA9Q NOS. We gave Alan permission to > change from our personal copyright to GPL. > > It has a lot of the features we'd developed, such as packet buffers and > pushdown functions for adding headers, complimentary to BSD pullup. > They made SIPP/IPv6 fairly easy to implement. > > > On 3/22/22 10:04 AM, Masataka Ohta wrote: > > Owen DeLong wrote: > > > >>> IPv6 optional header chain, even after it was widely recognized that > IPv4 options are useless/harmful and were deprecated is an example of IPv= 6 > bloat. > >>> > >>> Extensive use of link multicast for nothing is another example of > >>> IPv6 bloat. Note that IPv4 works without any multicast. > >> > >> Yes, but IPv6 works without any broadcast. At the time IPv6 was being > >> developed, broadcasts were rather inconvenient and it was believed > >> that ethernet switches (which were just beginning to be a thing then) > >> would facilitate more efficient capabilities by making extensive use > >> of link multicast instead of broadcast. > > > > No, the history around it is that there was some presentation > > in IPng WG by ATM people stating that ATM, or NBMA (Non-Broadcast > > Multiple Access)in general, is multicast capable though not > > broadcast capable, which was blindly believed by most, if not > > all excluding *me*, people there. > > > > Both Owen and Masataka are correct, in their own way. > > IPv4 options were recognized as harmful. SIPP used header chains instead= . > But the whole idea was to speed processing, eliminating hop-by-hop. > > Then the committees added back the hop by hop processing (type 0). > Terrible! > > Admittedly, I was also skeptical of packet shredding (what we called > ATM). Sadly, the Chicago NAP required ATM support, and that's where > my connections were located. > > > > It should be noted that IPv6 was less bloat because > > ND abandoned its initial goal to support IP over NBMA. > > > > Neighbor Discovery is/was agnostic to NBMA. Putting all the old > ARP and DHCP and other cruft into the IP-layer was my goal, so > that it would be forever link agnostic. > > > > > There is still a valid argument to be made that in a switched > > > ethernet world, multicast could offer efficiencies if networks were > > > better tuned to accommodate it vs. broadcast. > > > > That is against the CATENET model that each datalink only > > contain small number of hosts where broadcast is not a > > problem at all. Though, in CERN, single Ethernet with > > thousands of hosts was operated, of course poorly, it > > was abandoned to be inoperational a lot before IPv6, > > which is partly why IPv6 is inoperational. > > > > Yes, we were also getting a push from Fermi Labs and CERN for very > large numbers of nodes per link, rather than old ethernet maximum. > > That's the underlying design for Neighbor Discovery. Less chatty. > > Also, my alma mater was Michigan State University, operating the > largest bridged ethernet in the world in the '80s. Agreed, it was > "inoperational". My epiphany was splitting it with KA9Q routers. > > Suddenly the engineering building and the computing center each had > great throughput. Turns out it was the administration's IBM that > had been clogging the campus. Simple KA9Q routers didn't pass the > bad packets. That's how I'd become a routing over bridging convert. > > Still, there are data centers with thousand port switches. > > Also, TRILL. > > > -- > I tried to build a better future, a few times: > https://wayforward.archive.org/?site=3Dhttps%3A%2F%2Fwww.icei.org > > Dave T=C3=A4ht CEO, TekLibre, LLC > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink > --=20 Please send any postal/overnight deliveries to: Vint Cerf 1435 Woodhurst Blvd McLean, VA 22102 703-448-0965 until further notice --000000000000b7f3fd05dad2d983 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
actually, as I recall, the IAB proposed t= he use of the CLNP format but not the protocol - since it already ha= d a 128 bit address field=C2=A0 and catered to connectionless functionality= . It was assumed that the IAB was proposing to adopt the protocol and there= was an immediate and negative reaction to that.=C2=A0POISED was the result= .=C2=A0

v



On Tue, Mar 22, 2022 at 2:14 PM Dave Taht <dave.taht@gmail.com> wrote:
some ipv6 history I didn'= t know.

---------- Forwarded message ---------
From: William Allen Simpson <william.allen.simpson@gmail.com>
Date: Tue, Mar 22, 2022 at 12:09 PM
Subject: Re: IPv6 "bloat" history
To: <nanog@nanog.or= g>


Admitting to not having read every message in these threads,
but would like to highlight a bit of the history.

IMnsHO, the otherwise useful history is missing a few steps.

=C2=A0 1) The IAB selected ISO CLNP as the next version of IP.

=C2=A0 2) The IETF got angry, disbanded, replaced, and renamed IAB.

=C2=A0 3) On the Big-Internet list, my Practical Internet Protocol Extensio= ns
=C2=A0 =C2=A0 =C2=A0(PIPE) was an early proposal, and I'd registered V6= with IANA.

=C2=A0 =C2=A0 =C2=A0I was self-funding.=C2=A0 PIPE was cognizant of the nee= ds of ISPs and
=C2=A0 =C2=A0 =C2=A0deployment.

=C2=A0 4) Lixia Zhang wrote me that Steve Deering was proposing something =C2=A0 =C2=A0 =C2=A0similar, and urged us to pool our efforts.=C2=A0 That b= ecame Simple
=C2=A0 =C2=A0 =C2=A0Internet Protocol (SIP).=C2=A0 We used 64 bit addresses= .=C2=A0 We had a clear
=C2=A0 =C2=A0 =C2=A0path for migration, using the upper 32-bits for the ASN= and the old
=C2=A0 =C2=A0 =C2=A0IPv4 address in the lower 32-bits.=C2=A0 We had running= code.

=C2=A0 5) The IP Address Extension (IPAE) proposal had some overlapping fea= tures,
=C2=A0 =C2=A0 =C2=A0and we asked them to merge with us.=C2=A0 That added so= me complexity.

=C2=A0 6) The Paul Francis (the originator of NAT) Polymorphic Internet Pro= tocol
=C2=A0 =C2=A0 =C2=A0(PIP) had some overlapping features, so we also asked t= hem to merge
=C2=A0 =C2=A0 =C2=A0with us (July 1993).=C2=A0 More complexity in the proto= col header chaining.

=C2=A0 7) The result was SIPP.=C2=A0 We had 2 interoperable implementations= : Naval
=C2=A0 =C2=A0 =C2=A0Research Labs, and KA9Q NOS (Phil Karn and me).=C2=A0 T= here were others
=C2=A0 =C2=A0 =C2=A0well underway.

=C2=A0 8) As noted by John Curran, there was a committee of "powers th= at be".
=C2=A0 =C2=A0 =C2=A0After IETF had strong consensus for SIPP, and we had ru= nning code,
=C2=A0 =C2=A0 =C2=A0the "powers that be" decided to throw all tha= t away.

=C2=A0 9) The old junk was added back into IPv6 by committee.

There was also a mention that the Linux IP stack is fairly compact and
that IPv6 is somewhat smaller than the IPv4.=C2=A0 That's because the L= inux
stack was ported by Alan Cox from KA9Q NOS.=C2=A0 We gave Alan permission t= o
change from our personal copyright to GPL.

It has a lot of the features we'd developed, such as packet buffers and=
pushdown functions for adding headers, complimentary to BSD pullup.
They made SIPP/IPv6 fairly easy to implement.


On 3/22/22 10:04 AM, Masataka Ohta wrote:
> Owen DeLong wrote:
>
>>> IPv6 optional header chain, even after it was widely recognize= d that IPv4 options are useless/harmful and were deprecated is an example o= f IPv6 bloat.
>>>
>>> Extensive use of link multicast for nothing is another example= of
>>> IPv6 bloat. Note that IPv4 works without any multicast.
>>
>> Yes, but IPv6 works without any broadcast. At the time IPv6 was be= ing
>> developed, broadcasts were rather inconvenient and it was believed=
>> that ethernet switches (which were just beginning to be a thing th= en)
>> would facilitate more efficient capabilities by making extensive u= se
>> of link multicast instead of broadcast.
>
> No, the history around it is that there was some presentation
> in IPng WG by ATM people stating that ATM, or NBMA (Non-Broadcast
> Multiple Access)in general, is multicast capable though not
> broadcast capable, which was blindly believed by most, if not
> all excluding *me*, people there.
>

Both Owen and Masataka are correct, in their own way.

IPv4 options were recognized as harmful.=C2=A0 SIPP used header chains inst= ead.
But the whole idea was to speed processing, eliminating hop-by-hop.

Then the committees added back the hop by hop processing (type 0).
Terrible!

Admittedly, I was also skeptical of packet shredding (what we called
ATM).=C2=A0 Sadly, the Chicago NAP required ATM support, and that's whe= re
my connections were located.


> It should be noted that IPv6 was less bloat because
> ND abandoned its initial goal to support IP over NBMA.
>

Neighbor Discovery is/was agnostic to NBMA.=C2=A0 Putting all the old
ARP and DHCP and other cruft into the IP-layer was my goal, so
that it would be forever link agnostic.


>=C2=A0 > There is still a valid argument to be made that in a switch= ed
>=C2=A0 > ethernet world, multicast could offer efficiencies if netwo= rks were
>=C2=A0 > better tuned to accommodate it vs. broadcast.
>
> That is against the CATENET model that each datalink only
> contain small number of hosts where broadcast is not a
> problem at all. Though, in CERN, single Ethernet with
> thousands of hosts was operated, of course poorly, it
> was abandoned to be inoperational a lot before IPv6,
> which is partly why IPv6 is inoperational.
>

Yes, we were also getting a push from Fermi Labs and CERN for very
large numbers of nodes per link, rather than old ethernet maximum.

That's the underlying design for Neighbor Discovery.=C2=A0 Less chatty.=

Also, my alma mater was Michigan State University, operating the
largest bridged ethernet in the world in the '80s.=C2=A0 Agreed, it was=
"inoperational".=C2=A0 My epiphany was splitting it with KA9Q rou= ters.

Suddenly the engineering building and the computing center each had
great throughput.=C2=A0 Turns out it was the administration's IBM that<= br> had been clogging the campus.=C2=A0 Simple KA9Q routers didn't pass the=
bad packets.=C2=A0 That's how I'd become a routing over bridging co= nvert.

Still, there are data centers with thousand port switches.

Also, TRILL.


--
I tried to build a better future, a few times:
https://wayforward.archive.org/?sit= e=3Dhttps%3A%2F%2Fwww.icei.org

Dave T=C3=A4ht CEO, TekLibre, LLC
_______________________________________________
Starlink mailing list
Starlin= k@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink


--
Please send any postal/ove= rnight deliveries to:
Vint Cerf
1435 Woodhurst Blvd=C2= =A0
McLean, VA 22102
703-448-0965

<= div>until further notice



=
--000000000000b7f3fd05dad2d983--