From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oo1-xc30.google.com (mail-oo1-xc30.google.com [IPv6:2607:f8b0:4864:20::c30]) (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 C98B63CB40 for ; Thu, 10 Oct 2024 09:04:43 -0400 (EDT) Received: by mail-oo1-xc30.google.com with SMTP id 006d021491bc7-5e7ff0f41caso1015252eaf.1 for ; Thu, 10 Oct 2024 06:04:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1728565482; x=1729170282; darn=lists.bufferbloat.net; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=kiEQkMWykkoBnGqW64aVtx56ZQsLUJxjFQfqAki36Ek=; b=PUp0MZQRjlEvxWA5x5R1sWYuvdRnUiD2bXjq3ESZXJtBJcdjvyjgNCXNh76Dj/ucJA a/A+i5TgtzEC7LKSuq/JsT3+XWqIqaZd8EDCNa7g56nQtunwnHsb7xfkErciWnu6mrJE xp8J13PwBQD246fbfkDKLdou9yO0mzhJZwJbJlnoiA1UzowSfe9sxVqgiBm/Uuiy+ROi jNXev6vX9DHioXSbKc7Kh+gegMpqMaxX8JLCQHkhCLGHhp1AnE5F+PjFa6yfCkz8G99F HVxW0LU8P4mDCqJgbBfC6XGjK2cEo6HgPAK4rkAqwYnA1WWxFGJ9/ZDaacE1sse0162K j+Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728565482; x=1729170282; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=kiEQkMWykkoBnGqW64aVtx56ZQsLUJxjFQfqAki36Ek=; b=BkLutdbXq67vmTKHqNPiJKhDinL2KD8XYbPsxb1ccOqAgFjC6i35BmFFlTHG3wfMdq 1xaKYUnOhEt5ssyChpQuY8/jUIS2HcEi130Ve+ixZyxhTLPFUJehJUpf18xUwt340M3o zexnWsvDw5pvAVr4EcOWltSrnJGS9M0Ga/oxiG9xEHthMJptkc/UVbUtAU65B8Bai4U0 Zd5NROVFy4oA6SNTBlCnOq1+6WOgu7O9a+0KFwkqguOLO5HR4e1CuS1JxRgmNrYx8lNK 0AihRLWEBdZ2y2OGf3tuGIBb77xZui7o4PlIdWUHdYQ5I/o6d0xL3nAoUj6+ZEoNgyTN Xftg== X-Gm-Message-State: AOJu0YwcJCVVKT5H/YLFMF9bgSNUsiaAfzH7ti/H6XArGv7H5FdXNoyh zzbL4h85S8/w38oRaeNf8XC8UZCgkOJEFkSx7u1U+HVpZN/xaWhoKJ1QPQeQslY6fYQrpOWgH7o /IBiBJpkxHSjoInccUsuRW6roPjfFxg== X-Google-Smtp-Source: AGHT+IGmdx+rjGkm5n6pSybY9b2Rt6i10xZd4Gytyh6w4h8K13tm2fEkdRcVLh5o7dSj2NFGOAA1A1SmwF97f93pBhY= X-Received: by 2002:a05:6871:728b:b0:286:ee46:f194 with SMTP id 586e51a60fabf-2884d444c56mr2102645fac.17.1728565482213; Thu, 10 Oct 2024 06:04:42 -0700 (PDT) MIME-Version: 1.0 References: <295fe064-7128-403f-9cf8-f7a76720f90f@cis.upenn.edu> <45b1484f-ff71-401d-a5a8-e56f4f7ea08f@gmail.com> <133D21A5-4992-4446-BF3A-D613B4F6F3F1@sobco.com> <9507C0B2-CF24-48A3-8B3B-BA764A3E58D3@sobco.com> <1191418713.15094180.1727830223232@mail.yahoo.com> <29623329-6B8A-4DA5-A30B-83EEE15C7558@comcast.net> <645A35FD-23F6-4E43-9489-59DF8CE74285@icloud.com> <6B0500A3-414E-4A68-B528-822BB528F372@icloud.com> In-Reply-To: From: Dave Taht Date: Thu, 10 Oct 2024 06:04:28 -0700 Message-ID: To: bloat Content-Type: multipart/alternative; boundary="00000000000089d7be06241f036c" Subject: [Bloat] Fwd: [ih] booting linux on a 4004 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: Thu, 10 Oct 2024 13:04:43 -0000 --00000000000089d7be06241f036c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable vintage van jacobson rant from 1987, from a raging debate on the always excellent internet-history mailing list. ---------- Forwarded message --------- From: Craig Partridge via Internet-history Date: Thu, Oct 10, 2024 at 5:53=E2=80=AFAM Subject: Re: [ih] booting linux on a 4004 To: Greg Skinner Cc: Vint Cerf via Internet-history Hi Greg: Thanks for correcting my faulty memory. As partial recompense for being wrong, I'll note I have a partial set of the end2end-interest archives if there are questions. As recompense for my error, I offer the following tidbit: Posted-Date: Tue, 31 Mar 87 17:58:17 PST To: Craig Partridge Cc: end2end-tf@venera.isi.edu Subject: Re: Thinking about Congestion In-Reply-To: Your message of Fri, 27 Mar 87 08:43:19 EST. Date: Tue, 31 Mar 87 17:58:17 PST From: Van Jacobson Craig - Your note pushed one of my buttons: Sending a lot of data into a congested network doesn't improve transmit efficiency any more than disconnecting the collision detect wire on your ethernet would. Either action makes everyone on the net, including you, lose. There is always an optimum window size but computing it requires knowing how packet loss scales with window size. To first order, the scaling will be the exponential (1 - A)^W where W is the window size and A is a network dependent constant (0 < A < 1). For a long haul net, no-loss throughput will scale with window size like W/T where T is the round trip time. The effective throughput will go like the product of these two terms. For small W the linear term dominates and you see linear throughput increase with increasing window size. For large W the loss term dominates and you see exponential throughput decrease with increasing window size. For small A (low loss rates), the optimum window size will scale like -1/log(1-a). It's possible to do a more exact analysis. A few years ago a friend of mine was working on a tcp/ip implementation for a well known supercomputer manufacturer. At the time there was a huge debate in the company on whether to "modify" tcp. It seems that some cretin in management had decided that the only way to get good network performance was to do huge transfers, where "huge" was much larger than the 64K allowed by the tcp window size field. I was simulating very high performance fiber optic nets at the time and found this argument to be completely at odds with my results. I was so incensed that I wrote a little 5 page paper for my friend titled "Some notes on choosing an optimum transfer size" that started out: "The choice of network transfer size seems to have been driven by the idea that ``bigger is better''. While this reflects a good, American upbringing, it bears only faint resemblance to reality. In the unlikely event that a future decision is made on rational grounds, this note describes the mathematical basis for choice of window and transfer size." I'm afraid it went on in much the same tone (I must have been drunk when I wrote it) but I did summarize how to apply Erlang's and Hill's loss functions to tcp (the same analysis would apply to rdp - the only difference is rdp gains a factor of two in throughput over tcp at very high loss rates). If you're interested in the math, I'd be glad to send you extracts from this thing or the references I used. - Van On Thu, Oct 10, 2024 at 12:47=E2=80=AFAM Greg Skinner wrote: > > On Oct 5, 2024, at 5:42=E2=80=AFPM, Craig Partridge = wrote: > > > As someone who was in touch with Raj/KK and Van/Mike during the > development of congestion control. They were unaware of each other's wor= k > until spring of 1988, when they realized they were doing very similar > stuff. I think, someone (Dave Clark) in the End2End Research Group becam= e > aware of Raj & KK's work and invited them to come present to an E2E meeting > in early 1988 and E2E (more than IETF) was where Van was working out the > kinks in his congestion control work with Mike. > > Craig > > > I looked into this a bit, and discovered that Raj/KK and Van/Mike were al= l > at the 6th IETF, which took place in April 1987. [1] (It was a joint > meeting of the IETF and ANSI X3S3.3 Network and Transport Layer standards > groups.) Both teams presented their work at the meeting. > > On Sat, Oct 5, 2024 at 5:34=E2=80=AFPM John Day via Internet-history < > internet-history@elists.isoc.org> wrote: > >> The work of Jain=E2=80=99s DEC team existed at the same time and I belie= ve >> Jacobson=E2=80=99s original paper references it. >> >> As I said, at least it does congestion avoidance without causing >> congestion (unless under extreme conditions). >> >> I suspect that the main reason Jacobson didn=E2=80=99t adopt it was that= they >> were trying to maximize the data rate by running as close to congestion >> collapse as they could. While Jain=E2=80=99s work attempted to balance t= he >> trade-off between throughput and response time. But that is just policy >> they still could have used ECN to keep from being predatory and used ECN >> while waiting until the queue is full to mark the packets. That is what TCP >> use of ECN does now. Of course, I think that is bad choice because it >> generates lots of retransmissions. >> >> > Some of the reasons why Van/Mike took the approach they did were discusse= d > in a email message Van sent to the tcp-ip list. It included some > discussions that had taken place on the ietf and end2end-interest lists. > [2] IMO, it=E2=80=99s unfortunate that the existing archives of those lis= ts, > because we would be able to read the points of view expressed by the list > participants. > > When I asked Jain why his wasn=E2=80=99t adopted, he said he isn=E2=80=99= t an implementor, >> but an experimenter. >> >> But it is not uncommon to be so focused on the immediate problem to fail >> to notice the system implications. >> > > John, what could they have done that would have met your criteria and > yielded a deployable solution to the congestion problems existing at that > time in the timeframe that it was needed? IMO, their paper should be > assessed in that context. > > --gregbo > > [1] https://www.ietf.org/proceedings/06.pdf > [2] https://ee.lbl.gov/tcp.html > > --=20 ***** Craig Partridge's email account for professional society activities and mailing lists. --=20 Internet-history mailing list Internet-history@elists.isoc.org https://elists.isoc.org/mailman/listinfo/internet-history --=20 Dave T=C3=A4ht CSO, LibreQos --00000000000089d7be06241f036c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
vintage van jacobson rant from 1987, from a raging debate = on the always excellent =C2=A0internet-history mailing list.

---------- Forwar= ded message ---------
From: Craig Partridge via Internet-history <internet-history@elists.i= soc.org>
Date: Thu, Oct 10, 2024 at 5:53=E2=80=AFAM
Sub= ject: Re: [ih] booting linux on a 4004
To: Greg Skinner <gregskinner0@icloud.com>
Cc: Vint = Cerf via Internet-history <internet-history@elists.isoc.org>


Hi Greg:
Thanks for correcting my faulty memory.=C2=A0 =C2=A0As partial recompense f= or being
wrong, I'll note I have a partial set of the end2end-interest archives = if
there are questions.=C2=A0 As recompense for my error, I offer the followin= g
tidbit:

Posted-Date: Tue, 31 Mar 87 17:58:17 PST

To: Craig Partridge <craig@LOKI.BBN.COM>

Cc: end2end-= tf@venera.isi.edu

Subject: Re: Thinking about Congestion

In-Reply-To: Your message of Fri, 27 Mar 87 08:43:19 EST.

Date: Tue, 31 Mar 87 17:58:17 PST

From: Van Jacobson <van@lbl-csam.ARPA>


Craig -


Your note pushed one of my buttons:=C2=A0 Sending a lot of data

into a congested network doesn't improve transmit efficiency

any more than disconnecting the collision detect wire on

your ethernet would.=C2=A0 Either action makes everyone on the net,

including you, lose.


There is always an optimum window size but computing it requires

knowing how packet loss scales with window size.=C2=A0 To first order,

the scaling will be the exponential (1 - A)^W where W is the

window size and A is a network dependent constant (0 < A < 1).

For a long haul net, no-loss throughput will scale with window

size like W/T where T is the round trip time.=C2=A0 The effective

throughput will go like the product of these two terms.=C2=A0 For

small W the linear term dominates and you see linear throughput

increase with increasing window size.=C2=A0 For large W the loss term

dominates and you see exponential throughput decrease with

increasing window size.=C2=A0 For small A (low loss rates), the

optimum window size will scale like -1/log(1-a).


It's possible to do a more exact analysis.=C2=A0 A few years ago a

friend of mine was working on a tcp/ip implementation for a well

known supercomputer manufacturer.=C2=A0 At the time there was a huge

debate in the company on whether to "modify" tcp.=C2=A0 It seems = that

some cretin in management had decided that the only way to get

good network performance was to do huge transfers, where "huge"
was much larger than the 64K allowed by the tcp window size

field.=C2=A0 I was simulating very high performance fiber optic nets

at the time and found this argument to be completely at odds with

my results.=C2=A0 I was so incensed that I wrote a little 5 page paper

for my friend titled "Some notes on choosing an optimum transfer

size" that started out:


=C2=A0 =C2=A0 "The choice of network transfer size seems to have been<= br>
=C2=A0 =C2=A0 driven by the idea that ``bigger is better''.=C2=A0 W= hile this

=C2=A0 =C2=A0 reflects a good, American upbringing, it bears only faint

=C2=A0 =C2=A0 resemblance to reality.=C2=A0 In the unlikely event that a fu= ture

=C2=A0 =C2=A0 decision is made on rational grounds, this note describes the=

=C2=A0 =C2=A0 mathematical basis for choice of window and transfer size.&qu= ot;


I'm afraid it went on in much the same tone (I must have been

drunk when I wrote it) but I did summarize how to apply Erlang's

and Hill's loss functions to tcp (the same analysis would apply

to rdp - the only difference is rdp gains a factor of two in

throughput over tcp at very high loss rates).=C2=A0 If you're

interested in the math, I'd be glad to send you extracts from

this thing or the references I used.


=C2=A0 - Van


On Thu, Oct 10, 2024 at 12:47=E2=80=AFAM Greg Skinner <gregskinner0@icloud.com>=
wrote:

>
> On Oct 5, 2024, at 5:42=E2=80=AFPM, Craig Partridge <craig@tereschau.net> wrot= e:
>
>
> As someone who was in touch with Raj/KK and Van/Mike during the
> development of congestion control.=C2=A0 They were unaware of each oth= er's work
> until spring of 1988, when they realized they were doing very similar<= br> > stuff.=C2=A0 I think, someone (Dave Clark) in the End2End Research Gro= up became
> aware of Raj & KK's work and invited them to come present to a= n E2E meeting
> in early 1988 and E2E (more than IETF) was where Van was working out t= he
> kinks in his congestion control work with Mike.
>
> Craig
>
>
> I looked into this a bit, and discovered that Raj/KK and Van/Mike were= all
> at the 6th IETF, which took place in April 1987. [1] (It was a joint > meeting of the IETF and ANSI X3S3.3 Network and Transport Layer standa= rds
> groups.)=C2=A0 Both teams presented their work at the meeting.
>
> On Sat, Oct 5, 2024 at 5:34=E2=80=AFPM John Day via Internet-history &= lt;
> = internet-history@elists.isoc.org> wrote:
>
>> The work of Jain=E2=80=99s DEC team existed at the same time and I= believe
>> Jacobson=E2=80=99s original paper references it.
>>
>> As I said, at least it does congestion avoidance without causing >> congestion (unless under extreme conditions).
>>
>> I suspect that the main reason Jacobson didn=E2=80=99t adopt it wa= s that they
>> were trying to maximize the data rate by running as close to conge= stion
>> collapse as they could. While Jain=E2=80=99s work attempted to bal= ance the
>> trade-off between throughput and response time.=C2=A0 But that is = just policy
>> they still could have used ECN to keep from being predatory and us= ed ECN
>> while waiting until the queue is full to mark the packets. That is= what TCP
>> use of ECN does now. Of course, I think that is bad choice because= it
>> generates lots of retransmissions.
>>
>>
> Some of the reasons why Van/Mike took the approach they did were discu= ssed
> in a email message Van sent to the tcp-ip list.=C2=A0 It included some=
> discussions that had taken place on the ietf and end2end-interest list= s.
> [2] IMO, it=E2=80=99s unfortunate that the existing archives of those = lists,
> because we would be able to read the points of view expressed by the l= ist
> participants.
>
> When I asked Jain why his wasn=E2=80=99t adopted, he said he isn=E2=80= =99t an implementor,
>> but an experimenter.
>>
>> But it is not uncommon to be so focused on the immediate problem t= o fail
>> to notice the system implications.
>>
>
> John, what could they have done that would have met your criteria and<= br> > yielded a deployable solution to the congestion problems existing at t= hat
> time in the timeframe that it was needed?=C2=A0 IMO, their paper shoul= d be
> assessed in that context.
>
> --gregbo
>
> [1] https://www.ietf.org/proceedings/06.pdf
> [2] https://ee.lbl.gov/tcp.html
>
>

--
*****
Craig Partridge's email account for professional society activities and=
mailing lists.
--
Internet-history mailing list
Inter= net-history@elists.isoc.org
https://elists.isoc.org/mailman/listinfo/= internet-history


--
Dave T=C3=A4ht CSO, LibreQos
=
--00000000000089d7be06241f036c--