[NNagain] FCC NOI due dec 1 on broadband speed standards

[NNagain] FCC NOI due dec 1 on broadband speed standards

[Dave Taht]

https://docs.fcc.gov/public/attachments/FCC-23-89A1.pdf

Obviously I am going to have to weigh in on section 26, at least. I
would rather be writing code...

-- 
:( My old R&D campus is up for sale: https://tinyurl.com/yurtlab
Dave Täht CSO, LibreQos

Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

[rjmcmahon]

Thanks for this. It helps a lot.

I think a unified voice from this group around the metrics could be 
quite good. I do want to make sure iperf 2 covers this in a simple 
manner and very well so we in the chip business can catch issues very 
early in the process life cycle:

Regardless of the benchmark that we select for fixed broadband service, 
we believe it is
valuable for fixed providers to report on a wide range of download 
speeds and, in addition, multiple
upload speeds for each download speed. We invite commenters to suggest 
what they consider relevant
combinations of benchmark download and upload speeds that we should 
report for both fixed and mobile
broadband service. As part of their suggestions, we request that 
commenters consider the availability of
reliable and comprehensive data and suggest available sources.

Bob

> https://docs.fcc.gov/public/attachments/FCC-23-89A1.pdf
> 
> Obviously I am going to have to weigh in on section 26, at least. I
> would rather be writing code...

Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

[Livingood, Jason]

[-- Attachment #1.1: Type: text/plain, Size: 555 bytes --]

On the subject of how much bandwidth does one household need, here's a fun stat for you.


At the IETF’s 118th meeting<https://www.ietf.org/how/meetings/118/> last week (Nov 4 – 10, 2023), there were over 1,000 engineers in attendance. At peak there were 870 devices connected to the WiFi network. Peak bandwidth usage:

  *   Downstream peak ~750 Mbps
  *   Upstream ~250 Mbps



From my pre-meeting Twitter poll (https://twitter.com/jlivingood/status/1720060429311901873):

[A screenshot of a chat  Description automatically generated]

[-- Attachment #1.2: Type: text/html, Size: 6219 bytes --]

[-- Attachment #2: image001.png --]
[-- Type: image/png, Size: 119956 bytes --]

Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

[Dave Taht]

[-- Attachment #1.1: Type: text/plain, Size: 2362 bytes --]

As I noted also on the twitter thread for this, were I there, and
dishonest, (particularly were gobs of money on the table) I could easily
have permuted the bandwidth on both tests hugely upwards from a single
laptop by running continuous speedtests. But speedtests are not what we do
day in or out, and reflect normal usage not at all.

The 83% of people (experts!!!) that were wrong is ... mindboggling.

PS What wifi standard was at ietf? Is this still the old ciscos? The
headline bandwidths claimed for any version of wifi drop dramatically at
distance and with multiple users present.  So it might have taken a couple
laptops out of the thousand there to move the stats in a perverse
direction, now that I think about it.

Thank you for doing this experiment! While there are certainly also cases
were mass groupings of people totally saturate the underlying mac (more
than the perceived bandwidth - I have seen congestion collapse and a sea of
retransmits even in small wifi gatherings), the only number that seems a
bit off  in your test from a typical residential/small office is the
roughly 3.5x1 ratio between down and up. I am willing (for now) to put that
down to engineers doing actual work, rather than netflix.

I would so love to see more measurements like this at other wifi
concentration points, in offices and coffee shops. Packet captures too!!!!

On Tue, Nov 14, 2023 at 10:46 AM Livingood, Jason via Nnagain <
nnagain@lists.bufferbloat.net> wrote:

> On the subject of how much bandwidth does one household need, here's a fun
> stat for you.
>
>
>
> At the IETF’s 118th meeting <https://www.ietf.org/how/meetings/118/> last
> week (Nov 4 – 10, 2023), there were over 1,000 engineers in attendance. At
> peak there were 870 devices connected to the WiFi network. Peak bandwidth
> usage:
>
>    - Downstream peak ~750 Mbps
>    - Upstream ~250 Mbps
>
>
>
> From my pre-meeting Twitter poll (
> https://twitter.com/jlivingood/status/1720060429311901873):
>
> [image: A screenshot of a chat Description automatically generated]
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain
>


-- 
:( My old R&D campus is up for sale: https://tinyurl.com/yurtlab
Dave Täht CSO, LibreQos

[-- Attachment #1.2: Type: text/html, Size: 4674 bytes --]

[-- Attachment #2: image001.png --]
[-- Type: image/png, Size: 119956 bytes --]

Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

[Sebastian Moeller]

[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]

I guess I now am prepared to upgrade my home network into the ~1Gbps class, before inviting 1000 engineers over ;)

Joking aside, how representative is this ratio of users to peak traffic for what you know about residential users? I am not looking for anything more than a very coarse replay, like same order of magnitude or not ;)

On 14 November 2023 10:46:17 GMT-05:00, "Livingood, Jason via Nnagain" <nnagain@lists.bufferbloat.net> wrote:
>On the subject of how much bandwidth does one household need, here's a fun stat for you.
>
>
>At the IETF’s 118th meeting<https://www.ietf.org/how/meetings/118/> last week (Nov 4 – 10, 2023), there were over 1,000 engineers in attendance. At peak there were 870 devices connected to the WiFi network. Peak bandwidth usage:
>
>  *   Downstream peak ~750 Mbps
>  *   Upstream ~250 Mbps
>
>
>
From my pre-meeting Twitter poll (https://twitter.com/jlivingood/status/1720060429311901873):
>
>[A screenshot of a chat  Description automatically generated]

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 7033 bytes --]

Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

[Frantisek Borsik]

[-- Attachment #1.1: Type: text/plain, Size: 3817 bytes --]

Yeah, there were clearly visible Cisco APs, but I don't have a picture and
can't recall the exact model numbers, but Jason might be able to, I guess.

And for that experts being wrong - mindboggling NOT, at all.

Most of the people at IETF were not interested about L4S for example -
nobody I asked about it even knew about it at the event. Besides,
obviously, L4S guys and the "Red team". Met 2 journalists (sic! TWO) and
they told me they don't know about any other journalist at the event and
obviously, they didn't know about L4S or bufferbloat/latency/jitter being a
topic, at all. Jason knows one of these journalists, she promised to start
looking at it...so I hope she does.

Having said that - most of the IETF people still believes that "It's speed,
stupid!" (or bandwidth, at best)...not Stuart Cheshire's good ole maxim,
with latency in it.


All the best,

Frank

Frantisek (Frank) Borsik



https://www.linkedin.com/in/frantisekborsik

Signal, Telegram, WhatsApp: +421919416714

iMessage, mobile: +420775230885

Skype: casioa5302ca

frantisek.borsik@gmail.com


On Tue, Nov 14, 2023 at 5:07 PM Dave Taht via Nnagain <
nnagain@lists.bufferbloat.net> wrote:

> As I noted also on the twitter thread for this, were I there, and
> dishonest, (particularly were gobs of money on the table) I could easily
> have permuted the bandwidth on both tests hugely upwards from a single
> laptop by running continuous speedtests. But speedtests are not what we do
> day in or out, and reflect normal usage not at all.
>
> The 83% of people (experts!!!) that were wrong is ... mindboggling.
>
> PS What wifi standard was at ietf? Is this still the old ciscos? The
> headline bandwidths claimed for any version of wifi drop dramatically at
> distance and with multiple users present.  So it might have taken a couple
> laptops out of the thousand there to move the stats in a perverse
> direction, now that I think about it.
>
> Thank you for doing this experiment! While there are certainly also cases
> were mass groupings of people totally saturate the underlying mac (more
> than the perceived bandwidth - I have seen congestion collapse and a sea of
> retransmits even in small wifi gatherings), the only number that seems a
> bit off  in your test from a typical residential/small office is the
> roughly 3.5x1 ratio between down and up. I am willing (for now) to put that
> down to engineers doing actual work, rather than netflix.
>
> I would so love to see more measurements like this at other wifi
> concentration points, in offices and coffee shops. Packet captures too!!!!
>
> On Tue, Nov 14, 2023 at 10:46 AM Livingood, Jason via Nnagain <
> nnagain@lists.bufferbloat.net> wrote:
>
>> On the subject of how much bandwidth does one household need, here's a
>> fun stat for you.
>>
>>
>>
>> At the IETF’s 118th meeting <https://www.ietf.org/how/meetings/118/> last
>> week (Nov 4 – 10, 2023), there were over 1,000 engineers in attendance. At
>> peak there were 870 devices connected to the WiFi network. Peak bandwidth
>> usage:
>>
>>    - Downstream peak ~750 Mbps
>>    - Upstream ~250 Mbps
>>
>>
>>
>> From my pre-meeting Twitter poll (
>> https://twitter.com/jlivingood/status/1720060429311901873):
>>
>> [image: A screenshot of a chat Description automatically generated]
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
>>
>
>
> --
> :( My old R&D campus is up for sale: https://tinyurl.com/yurtlab
> Dave Täht CSO, LibreQos
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain
>

[-- Attachment #1.2: Type: text/html, Size: 7307 bytes --]

[-- Attachment #2: image001.png --]
[-- Type: image/png, Size: 119956 bytes --]

Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

[Dave Taht]

[-- Attachment #1.1: Type: text/plain, Size: 3034 bytes --]

On Tue, Nov 14, 2023 at 11:06 AM Dave Taht <dave.taht@gmail.com> wrote:

> As I noted also on the twitter thread for this, were I there, and
> dishonest, (particularly were gobs of money on the table) I could easily
> have permuted the bandwidth on both tests hugely upwards from a single
> laptop by running continuous speedtests. But speedtests are not what we do
> day in or out, and reflect normal usage not at all.
>
> The 83% of people (experts!!!) that were wrong is ... mindboggling.
>
> PS What wifi standard was at ietf? Is this still the old ciscos? The
> headline bandwidths claimed for any version of wifi drop dramatically at
> distance and with multiple users present.  So it might have taken a couple
> laptops out of the thousand there to move the stats in a perverse
> direction, now that I think about it.
>
> Thank you for doing this experiment! While there are certainly also cases
> were mass groupings of people totally saturate the underlying mac (more
> than the perceived bandwidth - I have seen congestion collapse and a sea of
> retransmits even in small wifi gatherings), the only number that seems a
> bit off  in your test from a typical residential/small office is the
> roughly 3.5x1 ratio between down and up. I am willing (for now) to put that
> down to engineers doing actual work, rather than netflix.
>

CORRECTION! 3x1. my fingers wanted it to be 5x1 (which is quite common in
many deployments), and then decided on their own to create 3.5x1... While
there is no ideal up/down ratio I firmly believe that 5x1 should be the
outside asymmetry, and there are compelling reasons.

I would be perfectly happy with a 10/10 connection (with bufferbloat
fixed), if only there was a way to pay for just that.


> I would so love to see more measurements like this at other wifi
> concentration points, in offices and coffee shops. Packet captures too!!!!
>
> On Tue, Nov 14, 2023 at 10:46 AM Livingood, Jason via Nnagain <
> nnagain@lists.bufferbloat.net> wrote:
>
>> On the subject of how much bandwidth does one household need, here's a
>> fun stat for you.
>>
>>
>>
>> At the IETF’s 118th meeting <https://www.ietf.org/how/meetings/118/> last
>> week (Nov 4 – 10, 2023), there were over 1,000 engineers in attendance. At
>> peak there were 870 devices connected to the WiFi network. Peak bandwidth
>> usage:
>>
>>    - Downstream peak ~750 Mbps
>>    - Upstream ~250 Mbps
>>
>>
>>
>> From my pre-meeting Twitter poll (
>> https://twitter.com/jlivingood/status/1720060429311901873):
>>
>> [image: A screenshot of a chat Description automatically generated]
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
>>
>
>
> --
> :( My old R&D campus is up for sale: https://tinyurl.com/yurtlab
> Dave Täht CSO, LibreQos
>


-- 
:( My old R&D campus is up for sale: https://tinyurl.com/yurtlab
Dave Täht CSO, LibreQos

[-- Attachment #1.2: Type: text/html, Size: 5512 bytes --]

[-- Attachment #2: image001.png --]
[-- Type: image/png, Size: 119956 bytes --]

Re: [NNagain] [EXTERNAL] Re: FCC NOI due dec 1 on broadband speed standards

[Livingood, Jason]

> As I noted also on the twitter thread for this, were I there, and dishonest, (particularly were gobs of money on the table) I could easily have permuted the bandwidth on both tests hugely upwards from a single laptop by running continuous speedtests. But speedtests are not what we do day in or out, and reflect normal usage not at all.

Exactly so. And certainly many speed tests were run I am sure. But in terms of everyday usage, I find it very interesting that this number of people used that amount of capacity. I have no doubt people were using P2P and doing large downloads, watching streaming video, and of course many peope on video conferences since everyone on site tended to also be running Meetecho from WG sessions. 

> PS What wifi standard was at ietf? Is this still the old ciscos? 

Cisco APs. Both 5 GHz and 2.4 GHz and this meeting they started the shift to WPA3. 

My broader objective is - like you - to help the world shift its mindset from 'bandwidth is the only solution' to 'bandwidth is important, but so is working latency'. Along these lines I'd like to see folks start to recognize that the single biggest way to improve end user QoE is probably less about bandwidth and more about working latency. 

Jason 

Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

[Sebastian Moeller]

Hi Dave,

On 14 November 2023 11:06:54 GMT-05:00, Dave Taht via Nnagain <nnagain@lists.bufferbloat.net> wrote:
>As I noted also on the twitter thread for this, were I there, and
>dishonest, (particularly were gobs of money on the table) I could easily
>have permuted the bandwidth on both tests hugely upwards from a single
>laptop by running continuous speedtests. But speedtests are not what we do
>day in or out, and reflect normal usage not at all.
>
>The 83% of people (experts!!!) that were wrong is ... mindboggling.


[SM] The optimist in me reads this as only 27% were really off... I also note the options had an odd scaling, neither liner, nor logarithmic, making it hard to make inferences.

>
>PS What wifi standard was at ietf? Is this still the old ciscos? The
>headline bandwidths claimed for any version of wifi drop dramatically at
>distance and with multiple users present.  So it might have taken a couple
>laptops out of the thousand there to move the stats in a perverse
>direction, now that I think about it.
>
>Thank you for doing this experiment! While there are certainly also cases
>were mass groupings of people totally saturate the underlying mac (more
>than the perceived bandwidth - I have seen congestion collapse and a sea of
>retransmits even in small wifi gatherings), the only number that seems a
>bit off  in your test from a typical residential/small office is the
>roughly 3.5x1 ratio between down and up. I am willing (for now) to put that
>down to engineers doing actual work, rather than netflix.

[SM] +1; the typical high down/up ratio for home users is partly a result of offering mostly heavily asymmetric links, users inherently learn what they can use a link for...

Regards
        Sebastian



>
>I would so love to see more measurements like this at other wifi
>concentration points, in offices and coffee shops. Packet captures too!!!!
>
>On Tue, Nov 14, 2023 at 10:46 AM Livingood, Jason via Nnagain <
>nnagain@lists.bufferbloat.net> wrote:
>
>> On the subject of how much bandwidth does one household need, here's a fun
>> stat for you.
>>
>>
>>
>> At the IETF’s 118th meeting <https://www.ietf.org/how/meetings/118/> last
>> week (Nov 4 – 10, 2023), there were over 1,000 engineers in attendance. At
>> peak there were 870 devices connected to the WiFi network. Peak bandwidth
>> usage:
>>
>>    - Downstream peak ~750 Mbps
>>    - Upstream ~250 Mbps
>>
>>
>>
>> From my pre-meeting Twitter poll (
>> https://twitter.com/jlivingood/status/1720060429311901873):
>>
>> [image: A screenshot of a chat Description automatically generated]
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
>>
>
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

[Livingood, Jason]

> Joking aside, how representative is this ratio of users to peak traffic for what you know about residential users? I am not looking for anything more than a very coarse replay, like same order of magnitude or not ;)

Based on my experience, this is representative in so far as: 
- People tend to use less bandwidth than they think [1]
- Downstream/upstream asymmetry remains is prevalent / normal
- The only real use of 1 Gbps is a speed test (artificial driver); there are no user applications that place those demands naturally on the network

Jason

[1] In a way, more bandwidth is like an insurance policy for possible usage and ensures capacity is not a constraint - and it has historically been a fair proxy, if indirect, for QoE.

Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

[Sebastian Moeller]

[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]

Hi Jason,

Thank you very much for the information!

Regards

On 14 November 2023 11:37:26 GMT-05:00, "Livingood, Jason" <jason_livingood@comcast.com> wrote:
>> Joking aside, how representative is this ratio of users to peak traffic for what you know about residential users? I am not looking for anything more than a very coarse replay, like same order of magnitude or not ;)
>
>Based on my experience, this is representative in so far as: 
>- People tend to use less bandwidth than they think [1]
>- Downstream/upstream asymmetry remains is prevalent / normal
>- The only real use of 1 Gbps is a speed test (artificial driver); there are no user applications that place those demands naturally on the network
>
>Jason
>
>[1] In a way, more bandwidth is like an insurance policy for possible usage and ensures capacity is not a constraint - and it has historically been a fair proxy, if indirect, for QoE.
>
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 1548 bytes --]

Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

[Vint Cerf]

[-- Attachment #1.1.1: Type: text/plain, Size: 1187 bytes --]

if they had not been all together they would have been consuming tons of
video capacity doing video conference calls....

:-))
v


On Tue, Nov 14, 2023 at 10:46 AM Livingood, Jason via Nnagain <
nnagain@lists.bufferbloat.net> wrote:

> On the subject of how much bandwidth does one household need, here's a fun
> stat for you.
>
>
>
> At the IETF’s 118th meeting <https://www.ietf.org/how/meetings/118/> last
> week (Nov 4 – 10, 2023), there were over 1,000 engineers in attendance. At
> peak there were 870 devices connected to the WiFi network. Peak bandwidth
> usage:
>
>    - Downstream peak ~750 Mbps
>    - Upstream ~250 Mbps
>
>
>
> From my pre-meeting Twitter poll (
> https://twitter.com/jlivingood/status/1720060429311901873):
>
> [image: A screenshot of a chat Description automatically generated]
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain
>


-- 
Please send any postal/overnight deliveries to:
Vint Cerf
Google, LLC
1900 Reston Metro Plaza, 16th Floor
Reston, VA 20190
+1 (571) 213 1346


until further notice

[-- Attachment #1.1.2: Type: text/html, Size: 3543 bytes --]

[-- Attachment #1.2: image001.png --]
[-- Type: image/png, Size: 119956 bytes --]

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 3995 bytes --]

Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

[Dave Taht]

On Tue, Nov 14, 2023 at 12:25 PM Vint Cerf via Nnagain
<nnagain@lists.bufferbloat.net> wrote:
>
> if they had not been all together they would have been consuming tons of video capacity doing video conference calls....

There were plenty of remote attendees. One feed per room = ?

Videoconferencing capacity use is another statistic that is not really
widely available. I do not know of any "modern" videoconferencing
service that makes available bandwidth, loss, frame rate, frame size,
"quality" statistics for any given session.Do they? Does IETF
meetecho?  Is there a federal reporting requirement?

 I primarily use galene.org: that does all that for me (since I have
source code and have had my fingers in videoconferencing apps for many
years, and every time I get a few minutes try to improve "gcc"
further. A decent frame rate is usually around 500k/sec on the up,
750k peak, and describing what happens on the down and how it scales
by user beyond the scope of what I want to write today..

facetime is the videoconferencing "pig" at up to 4mb/sec.

?


>
> :-))
> v
>
>
> On Tue, Nov 14, 2023 at 10:46 AM Livingood, Jason via Nnagain <nnagain@lists.bufferbloat.net> wrote:
>>
>> On the subject of how much bandwidth does one household need, here's a fun stat for you.
>>
>>
>>
>> At the IETF’s 118th meeting last week (Nov 4 – 10, 2023), there were over 1,000 engineers in attendance. At peak there were 870 devices connected to the WiFi network. Peak bandwidth usage:
>>
>> Downstream peak ~750 Mbps
>> Upstream ~250 Mbps
>>
>>
>>
>> From my pre-meeting Twitter poll (https://twitter.com/jlivingood/status/1720060429311901873):
>>
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
>
>
>
> --
> Please send any postal/overnight deliveries to:
> Vint Cerf
> Google, LLC
> 1900 Reston Metro Plaza, 16th Floor
> Reston, VA 20190
> +1 (571) 213 1346
>
>
> until further notice
>
>
>
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain



-- 
:( My old R&D campus is up for sale: https://tinyurl.com/yurtlab
Dave Täht CSO, LibreQos

Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

[Jeremy Austin]

[-- Attachment #1: Type: text/plain, Size: 1453 bytes --]

On Tue, Nov 14, 2023 at 6:46 AM Livingood, Jason via Nnagain <
nnagain@lists.bufferbloat.net> wrote:

> On the subject of how much bandwidth does one household need, here's a fun
> stat for you.
>
>
>
> At the IETF’s 118th meeting <https://www.ietf.org/how/meetings/118/> last
> week (Nov 4 – 10, 2023), there were over 1,000 engineers in attendance. At
> peak there were 870 devices connected to the WiFi network. Peak bandwidth
> usage:
>
>    - Downstream peak ~750 Mbps
>    - Upstream ~250 Mbps
>
>
How was this calculated? That's an unusually high ratio of up to down, so
my suspicion is that they aren't time correlated; they're also not /normal/
or /evening/ peaks, I'm expecting.

There's a big difference between individual peaks of upload and aggregate
peaks of upload; most people aren't streaming high symmetric bandwidth
simultaneously. Consequently a peak busy hour online load, I'm finding, is
still much more like 8:1 over all users (idle and active), in Preseem's
data set.

In addition to speed tests being, like democracy, the worst form of
government except for all the others that have been tried, it would be
instructive both for end users and ISPs to choose, agree on and understand
specific percentiles of expected performance at idle and at peak busy hour.

Has anyone solved the math problem of distinguishing (from outside) a
constraint in supply from a reduction in demand?

Jeremy

[-- Attachment #2: Type: text/html, Size: 2919 bytes --]

Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

[Jack Haverty]

[-- Attachment #1: Type: text/plain, Size: 1789 bytes --]

If video conferencing worked well enough, they would not have to all get 
together in one place and would instead hold IETF meetings online ...?

Did anyone measure latency?   Does anyone measure throughput of "useful" 
traffic - e.g., excluding video/audio data that didn't arrive in time to 
be actually used on the screen or speaker?

Jack Haverty


On 11/14/23 09:25, Vint Cerf via Nnagain wrote:
> if they had not been all together they would have been consuming tons 
> of video capacity doing video conference calls....
>
> :-))
> v
>
>
> On Tue, Nov 14, 2023 at 10:46 AM Livingood, Jason via Nnagain 
> <nnagain@lists.bufferbloat.net> wrote:
>
>     On the subject of how much bandwidth does one household need,
>     here's a fun stat for you.
>
>     At the IETF’s118th meeting
>     <https://www.ietf.org/how/meetings/118/>last week (Nov 4 – 10,
>     2023), there were over 1,000 engineers in attendance. At peak
>     there were 870 devices connected to the WiFi network. Peak
>     bandwidth usage:
>
>       * Downstream peak ~750 Mbps
>       * Upstream ~250 Mbps
>
>     From my pre-meeting Twitter poll
>     (https://twitter.com/jlivingood/status/1720060429311901873):
>
>     A screenshot of a chat Description automatically generated
>
>     _______________________________________________
>     Nnagain mailing list
>     Nnagain@lists.bufferbloat.net
>     https://lists.bufferbloat.net/listinfo/nnagain
>
>
>
> -- 
> Please send any postal/overnight deliveries to:
> Vint Cerf
> Google, LLC
> 1900 Reston Metro Plaza, 16th Floor
> Reston, VA 20190
> +1 (571) 213 1346
>
>
> until further notice
>
>
>
>
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain

[-- Attachment #2.1: Type: text/html, Size: 6318 bytes --]

[-- Attachment #2.2: image001.png --]
[-- Type: image/png, Size: 119956 bytes --]

Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

[Sebastian Moeller]

Hi Jeremy,


> On Nov 14, 2023, at 12:58, Jeremy Austin via Nnagain <nnagain@lists.bufferbloat.net> wrote:
> 
> 
> 
> On Tue, Nov 14, 2023 at 6:46 AM Livingood, Jason via Nnagain <nnagain@lists.bufferbloat.net> wrote:
> On the subject of how much bandwidth does one household need, here's a fun stat for you.
> 
>  
> 
> At the IETF’s 118th meeting last week (Nov 4 – 10, 2023), there were over 1,000 engineers in attendance. At peak there were 870 devices connected to the WiFi network. Peak bandwidth usage:
> 
> 	• Downstream peak ~750 Mbps
> 	• Upstream ~250 Mbps
> 
> How was this calculated? That's an unusually high ratio of up to down, so my suspicion is that they aren't time correlated; they're also not /normal/ or /evening/ peaks, I'm expecting.

	[SM] Given that this is from a conference network, I think it is expected that the pattern does not match typical end-user traffic, no?


> 
> There's a big difference between individual peaks of upload and aggregate peaks of upload; most people aren't streaming high symmetric bandwidth simultaneously.

	[SM] Which is good, at current rates of over-subscription (or under-provisioning for the glass half empty folks) such a shift in usage behavior likely would not result in happiness all around?


> Consequently a peak busy hour online load, I'm finding, is still much more like 8:1 over all users (idle and active), in Preseem's data set.

	[SM] But this is end users that have been trained over decades to operate on heavily asymmetric links and that adjusted their usage patterns to match the "possible" while we might expect the network experts at IETF to have different expectations? (Then again these folks likely also are users of normal home internet links).


> 
> In addition to speed tests being, like democracy, the worst form of government except for all the others that have been tried, it would be instructive both for end users and ISPs to choose, agree on and understand specific percentiles of expected performance at idle and at peak busy hour.

	[SM] That will not be easy to achieve.


> Has anyone solved the math problem of distinguishing (from outside) a constraint in supply from a reduction in demand?

	[SM] Keep in mind that the former can cause the latter, if connectivity/responsiveness is too bad, people might shift to do other things there y reducing the measurable load, but not the conceptual demand (as they might prefer a workable internet access).

Regards
	Sebastian


> 
> Jeremy
> 
> 
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

[rjmcmahon]

iperf 2 supports two features relevant here - one for a live video 
source (isochronous) and the other for DASH like protocols (--burst-size 
& --burst-period.) Note: One can select the CCA to influence pacing or 
not on bursts. These tests are under utilized and not well known. Also, 
don't forget --trip-times on the client

--isochronous[=fps:mean,stdev]
send isochronous traffic with frequency frames per second and load 
defined by mean and standard deviation using a log normal distribution, 
defaults to 60:20m,0. (Note: Here the suffixes indicate bytes/sec or 
bits/sec per use of uppercase or lowercase, respectively. Also the p 
suffix is supported to set the burst size in packets, e.g. 
isochronous=2:25p will send two 25 packet bursts every second, or one 25 
packet burst every 0.5 seconds.)

--burst-period n
Set the burst period in seconds. Defaults to one second. (Note: assumed 
use case is low duty cycle traffic bursts)
--burst-size n
Set the burst size in bytes. Defaults to 1M if no value is given.

The server side output then provides better insights on the burst rate 
and the duty cycle (DC), as well as the end to end xfer time.

Burst
=====

root@raspberrypi:~# iperf -s -i 1 -e
------------------------------------------------------------
Server listening on TCP port 5001 with pid 2241
Read buffer size:  128 KByte (Dist bin width=16.0 KByte)
TCP congestion control default cubic
TCP window size:  128 KByte (default)
------------------------------------------------------------
[  1] local 192.168.1.31%eth0 port 5001 connected with 192.168.1.32 port 
55512 (burst-period=1.00s) (trip-times) (sock=4) (peer 2.1.10-dev) 
(icwnd/mss/irtt=14/1448/213) on 2023-11-14 10:01:05.936 (PST)
[ ID] Burst (start-end)  Transfer     Bandwidth       XferTime  (DC%)    
  Reads=Dist          NetPwr
[  1] 0.00-0.01 sec  1.00 MBytes   812 Mbits/sec  10.338 ms (1%)    
100=95:5:0:0:0:0:0:09812
[  1] 1.00-1.01 sec  1.00 MBytes   852 Mbits/sec   9.849 ms (0.98%)    
144=141:3:0:0:0:0:0:010810
[  1] 2.00-2.01 sec  1.00 MBytes   817 Mbits/sec  10.268 ms (1%)    
118=109:4:5:0:0:0:0:09946
[  1] 0.00-3.00 sec  3.00 MBytes  8.38 Mbits/sec  
10.152/9.849/10.338/0.264 ms  362=345:12:5:0:0:0:0:0

root@raspberrypi:~# iperf -c 192.168.1.31 --burst-size 1M --trip-times 
-i 1 -e --burst-period 1 -t 3
------------------------------------------------------------
Client connecting to 192.168.1.31, TCP port 5001 with pid 84171 (1/0 
flows/load)
Write buffer size: 131072 Byte  Burst size: 1048576 Byte
Bursting: 1.00 MByte every 1.00 second(s)
TCP congestion control using cubic
TOS set to 0x0 (Nagle on)
TCP window size: 85.0 KByte (default)
Event based writes (pending queue watermark at 16384 bytes)
------------------------------------------------------------
[  1] local 192.168.1.32%eth0 port 55512 connected with 192.168.1.31 
port 5001 (prefetch=16384) (trip-times) (sock=3) 
(icwnd/mss/irtt=14/1448/245) (ct=0.41 ms) on 2023-11-14 10:01:05.936 
(PST)
[ ID] Interval        Transfer    Bandwidth       Write/Err  Rtry     
Cwnd/RTT(var)        NetPwr
[  1] 0.00-1.00 sec  1.00 MBytes  8.39 Mbits/sec  8/0         0      
237K/1374(122) us  763
[  1] 1.00-2.00 sec  1.00 MBytes  8.39 Mbits/sec  8/0         0      
236K/1043(138) us  1005
[  1] 2.00-3.00 sec  1.00 MBytes  8.39 Mbits/sec  8/0         0      
179K/1490(196) us  704
[  1] 0.00-3.01 sec  3.00 MBytes  8.36 Mbits/sec  24/0         0      
179K/2591(2348) us  403

Isoch
=====

root@raspberrypi:~# iperf -s -i 1 -e --histograms
------------------------------------------------------------
Server listening on TCP port 5001 with pid 2253
Read buffer size:  128 KByte (Dist bin width=16.0 KByte)
TCP congestion control default cubic
Enabled receive histograms bin-width=0.100 ms, bins=100000 (clients 
should use --trip-times)
TCP window size:  128 KByte (default)
------------------------------------------------------------
[  1] local 192.168.1.31%eth0 port 5001 connected with 192.168.1.32 port 
39188 (isoch) (trip-times) (sock=4) (peer 2.1.10-dev) 
(icwnd/mss/irtt=14/1448/214) on 2023-11-14 10:06:54.178 (PST)
[ ID] Interval        Transfer    Bandwidth    Burst Latency 
avg/min/max/stdev (cnt/size) NetPwr  Reads=Dist
[  1] 0.00-1.00 sec  2.37 MBytes  19.9 Mbits/sec  
0.666/0.448/2.084/0.210 ms (60/41501) 3739  432=430:2:0:0:0:0:0:0
[  1] 0.00-1.00 sec F8-PDF: 
bin(w=100us):cnt(60)=5:2,6:21,7:20,8:12,9:3,10:1,21:1 
(5.00/95.00/99.7%=6/9/21,Outliers=1,obl/obu=0/0) (2.084 
ms/1699985214.182410)
[  1] 1.00-2.00 sec  2.47 MBytes  20.7 Mbits/sec  
0.657/0.458/0.944/0.106 ms (60/43104) 3939  457=455:2:0:0:0:0:0:0
[  1] 1.00-2.00 sec F8-PDF: 
bin(w=100us):cnt(60)=5:4,6:14,7:21,8:17,9:3,10:1 
(5.00/95.00/99.7%=5/9/10,Outliers=0,obl/obu=0/0) (0.944 
ms/1699985215.281164)
[  1] 2.00-3.00 sec  2.41 MBytes  20.2 Mbits/sec  
0.734/0.548/1.047/0.111 ms (60/42095) 3443  197=149:18:24:6:0:0:0:0
[  1] 2.00-3.00 sec F8-PDF: 
bin(w=100us):cnt(60)=6:5,7:17,8:23,9:10,10:3,11:2 
(5.00/95.00/99.7%=6/10/11,Outliers=0,obl/obu=0/0) (1.047 
ms/1699985216.881204)
[  1] 0.00-3.00 sec  7.29 MBytes  20.4 Mbits/sec  
0.686/0.448/2.084/0.153 ms (181/42227) 3712  1088=1035:22:25:6:0:0:0:0
[  1] 0.00-3.00 sec F8(f)-PDF: 
bin(w=100us):cnt(181)=5:6,6:40,7:58,8:53,9:16,10:5,11:2,21:1 
(5.00/95.00/99.7%=6/9/21,Outliers=1,obl/obu=0/0) (2.084 
ms/1699985214.182410)


root@raspberrypi:~# iperf -c 192.168.1.31 --burst-size 1M --trip-times 
-i 1 -e --isochronous=60:20m,4m -t 3
------------------------------------------------------------
Client connecting to 192.168.1.31, TCP port 5001 with pid 84182 (1/0 
flows/load)
Write buffer size: 131072 Byte  Burst size: 1048576 Byte
Isochronous: 60.00 frames/sec mean=20.0 Mbit/s, stddev=4.00 Mbit/s, 
Period/IPG=16.67/0.000 ms
TCP congestion control using cubic
TOS set to 0x0 (Nagle on)
TCP window size: 85.0 KByte (default)
Event based writes (pending queue watermark at 16384 bytes)
------------------------------------------------------------
[  1] local 192.168.1.32%eth0 port 39188 connected with 192.168.1.31 
port 5001 (prefetch=16384) (isoch) (trip-times) (sock=3) 
(icwnd/mss/irtt=14/1448/259) (ct=0.42 ms) on 2023-11-14 10:06:54.178 
(PST)
[ ID] Interval        Transfer     Bandwidth      Write/Err  Rtry     
Cwnd/RTT     isoch:tx/miss/slip  NetPwr
[  1] 0.00-1.00 sec  2.37 MBytes  19.9 Mbits/sec  60/0        0      
124K/525 us         61/0/04743
[  1] 1.00-2.00 sec  2.47 MBytes  20.7 Mbits/sec  60/0        0      
124K/479 us         60/0/05399
[  1] 2.00-3.00 sec  2.41 MBytes  20.2 Mbits/sec  60/0        0      
134K/578 us         60/0/04370
[  1] 0.00-3.04 sec  7.29 MBytes  20.1 Mbits/sec  181/0        0      
134K/596 us        182/0/04221
[  1] Isoch schedule errors (mean/min/max/stdev) = 
0.079/0.057/0.110/0.005 ms


Bob
> On Tue, Nov 14, 2023 at 12:25 PM Vint Cerf via Nnagain
> <nnagain@lists.bufferbloat.net> wrote:
>> 
>> if they had not been all together they would have been consuming tons 
>> of video capacity doing video conference calls....
> 
> There were plenty of remote attendees. One feed per room = ?
> 
> Videoconferencing capacity use is another statistic that is not really
> widely available. I do not know of any "modern" videoconferencing
> service that makes available bandwidth, loss, frame rate, frame size,
> "quality" statistics for any given session.Do they? Does IETF
> meetecho?  Is there a federal reporting requirement?
> 
>  I primarily use galene.org: that does all that for me (since I have
> source code and have had my fingers in videoconferencing apps for many
> years, and every time I get a few minutes try to improve "gcc"
> further. A decent frame rate is usually around 500k/sec on the up,
> 750k peak, and describing what happens on the down and how it scales
> by user beyond the scope of what I want to write today..
> 
> facetime is the videoconferencing "pig" at up to 4mb/sec.
> 
> ?
> 
> 
>> 
>> :-))
>> v
>> 
>> 
>> On Tue, Nov 14, 2023 at 10:46 AM Livingood, Jason via Nnagain 
>> <nnagain@lists.bufferbloat.net> wrote:
>>> 
>>> On the subject of how much bandwidth does one household need, here's 
>>> a fun stat for you.
>>> 
>>> 
>>> 
>>> At the IETF’s 118th meeting last week (Nov 4 – 10, 2023), there were 
>>> over 1,000 engineers in attendance. At peak there were 870 devices 
>>> connected to the WiFi network. Peak bandwidth usage:
>>> 
>>> Downstream peak ~750 Mbps
>>> Upstream ~250 Mbps
>>> 
>>> 
>>> 
>>> From my pre-meeting Twitter poll 
>>> (https://twitter.com/jlivingood/status/1720060429311901873):
>>> 
>>> _______________________________________________
>>> Nnagain mailing list
>>> Nnagain@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/nnagain
>> 
>> 
>> 
>> --
>> Please send any postal/overnight deliveries to:
>> Vint Cerf
>> Google, LLC
>> 1900 Reston Metro Plaza, 16th Floor
>> Reston, VA 20190
>> +1 (571) 213 1346
>> 
>> 
>> until further notice
>> 
>> 
>> 
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

[Sebastian Moeller]

Hi Jack,


> On Nov 14, 2023, at 13:02, Jack Haverty via Nnagain <nnagain@lists.bufferbloat.net> wrote:
> 
> If video conferencing worked well enough, they would not have to all get together in one place and would instead hold IETF meetings online ...?

	[SM] Turns out that humans are social creatures, and some things work better face-to-face and in the hallway (and if that is only building trust and sympathy) than over any remote technology.


> Did anyone measure latency?   Does anyone measure throughput of "useful" traffic - e.g., excluding video/audio data that didn't arrive in time to be actually used on the screen or speaker?

	[SM] Utility is in the eye of the beholder, no?


> 
> Jack Haverty
> 
> 
> On 11/14/23 09:25, Vint Cerf via Nnagain wrote:
>> if they had not been all together they would have been consuming tons of video capacity doing video conference calls....
>> 
>> :-))
>> v
>> 
>> 
>> On Tue, Nov 14, 2023 at 10:46 AM Livingood, Jason via Nnagain <nnagain@lists.bufferbloat.net> wrote:
>> On the subject of how much bandwidth does one household need, here's a fun stat for you.
>> 
>>  
>> At the IETF’s 118th meeting last week (Nov 4 – 10, 2023), there were over 1,000 engineers in attendance. At peak there were 870 devices connected to the WiFi network. Peak bandwidth usage:
>> 
>> 	• Downstream peak ~750 Mbps
>> 	• Upstream ~250 Mbps
>>  
>> From my pre-meeting Twitter poll (https://twitter.com/jlivingood/status/1720060429311901873):
>> 
>> <image001.png>
>> 
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
>> 
>> 
>> -- 
>> Please send any postal/overnight deliveries to:
>> Vint Cerf
>> Google, LLC
>> 1900 Reston Metro Plaza, 16th Floor
>> Reston, VA 20190
>> +1 (571) 213 1346
>> 
>> 
>> until further notice
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Nnagain mailing list
>> 
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
> 
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

[rjmcmahon]

It's frustrating to me that even experts here don't measure latency as a 
first priority. The tooling has been available for years to do this. And 
it's only getting better and more feature rich, e.g. bounce-back.

--bounceback[=n]
run a TCP bounceback or rps test with optional number writes in a burst 
per value of n. The default is ten writes every period and the default 
period is one second (Note: set size with --bounceback-request). See 
NOTES on clock unsynchronized detections.
--bounceback-hold n
request the server to insert a delay of n milliseconds between its read 
and write (default is no delay)
--bounceback-no-quickack
request the server not set the TCP_QUICKACK socket option (disabling TCP 
ACK delays) during a bounceback test (see NOTES)
--bounceback-period[=n]
request the client schedule its send(s) every n seconds (default is one 
second, use zero value for immediate or continuous back to back)
--bounceback-request n
set the bounceback request size in units bytes. Default value is 100 
bytes.
--bounceback-reply n
set the bounceback reply size in units bytes. This supports asymmetric 
message sizes between the request and the reply. Default value is zero, 
which uses the value of --bounceback-request.
--bounceback-txdelay n
request the client to delay n seconds between the start of the working 
load and the bounceback traffic (default is no delay)

https://iperf2.sourceforge.io/iperf-manpage.html

Bob
> If video conferencing worked well enough, they would not have to all
> get together in one place and would instead hold IETF meetings online
> ...?
> 
> Did anyone measure latency?   Does anyone measure throughput of
> "useful" traffic - e.g., excluding video/audio data that didn't arrive
> in time to be actually used on the screen or speaker?
> 
> Jack Haverty
> 
> On 11/14/23 09:25, Vint Cerf via Nnagain wrote:
> 
>> if they had not been all together they would have been consuming
>> tons of video capacity doing video conference calls....
>> 
>> :-))
>> v
>> 
>> On Tue, Nov 14, 2023 at 10:46 AM Livingood, Jason via Nnagain
>> <nnagain@lists.bufferbloat.net> wrote:
>> 
>>> On the subject of how much bandwidth does one household need,
>>> here's a fun stat for you.
>>> 
>>> At the IETF’s 118th meeting [1] last week (Nov 4 – 10, 2023),
>>> there were over 1,000 engineers in attendance. At peak there were
>>> 870 devices connected to the WiFi network. Peak bandwidth usage:
>>> 
>>> * Downstream peak ~750 Mbps
>>> * Upstream ~250 Mbps
>>> 
>>> From my pre-meeting Twitter poll
>>> (https://twitter.com/jlivingood/status/1720060429311901873):
>>> 
>>> _______________________________________________
>>> Nnagain mailing list
>>> Nnagain@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/nnagain
>> 
>> --
>> 
>> Please send any postal/overnight deliveries to:
>> 
>> Vint Cerf
>> Google, LLC
>> 1900 Reston Metro Plaza, 16th Floor
>> Reston, VA 20190
>> +1 (571) 213 1346
>> 
>> until further notice
>> 
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
> 
> 
> 
> Links:
> ------
> [1] https://www.ietf.org/how/meetings/118/
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

[rjmcmahon]

Also, don't forget to measure with working-loads too

--working-load[=up|down|bidir][,n]
request a concurrent working load, currently TCP stream(s), defaults to 
full duplex (or bidir) unless the up or down option is provided. The 
number of TCP streams defaults to 1 and can be changed via the n value, 
e.g. --working-load=down,4 will use four TCP streams from server to the 
client as the working load. The IP ToS will be BE (0x0) for working load 
traffic.
--working-load-cca
Set the congestion control algorithm to be used for TCP working loads

Maybe keep a few rasberry pi's in one's backback with iperf 2? That way 
you're always prepared for latency emergencies. The Rpi5 has a TCXO for 
it's clock.

Bob
> It's frustrating to me that even experts here don't measure latency as
> a first priority. The tooling has been available for years to do this.
> And it's only getting better and more feature rich, e.g. bounce-back.
> 
> --bounceback[=n]
> run a TCP bounceback or rps test with optional number writes in a
> burst per value of n. The default is ten writes every period and the
> default period is one second (Note: set size with
> --bounceback-request). See NOTES on clock unsynchronized detections.
> --bounceback-hold n
> request the server to insert a delay of n milliseconds between its
> read and write (default is no delay)
> --bounceback-no-quickack
> request the server not set the TCP_QUICKACK socket option (disabling
> TCP ACK delays) during a bounceback test (see NOTES)
> --bounceback-period[=n]
> request the client schedule its send(s) every n seconds (default is
> one second, use zero value for immediate or continuous back to back)
> --bounceback-request n
> set the bounceback request size in units bytes. Default value is 100 
> bytes.
> --bounceback-reply n
> set the bounceback reply size in units bytes. This supports asymmetric
> message sizes between the request and the reply. Default value is
> zero, which uses the value of --bounceback-request.
> --bounceback-txdelay n
> request the client to delay n seconds between the start of the working
> load and the bounceback traffic (default is no delay)
> 
> https://iperf2.sourceforge.io/iperf-manpage.html
> 
> Bob
>> If video conferencing worked well enough, they would not have to all
>> get together in one place and would instead hold IETF meetings online
>> ...?
>> 
>> Did anyone measure latency?   Does anyone measure throughput of
>> "useful" traffic - e.g., excluding video/audio data that didn't arrive
>> in time to be actually used on the screen or speaker?
>> 
>> Jack Haverty
>> 
>> On 11/14/23 09:25, Vint Cerf via Nnagain wrote:
>> 
>>> if they had not been all together they would have been consuming
>>> tons of video capacity doing video conference calls....
>>> 
>>> :-))
>>> v
>>> 
>>> On Tue, Nov 14, 2023 at 10:46 AM Livingood, Jason via Nnagain
>>> <nnagain@lists.bufferbloat.net> wrote:
>>> 
>>>> On the subject of how much bandwidth does one household need,
>>>> here's a fun stat for you.
>>>> 
>>>> At the IETF’s 118th meeting [1] last week (Nov 4 – 10, 2023),
>>>> there were over 1,000 engineers in attendance. At peak there were
>>>> 870 devices connected to the WiFi network. Peak bandwidth usage:
>>>> 
>>>> * Downstream peak ~750 Mbps
>>>> * Upstream ~250 Mbps
>>>> 
>>>> From my pre-meeting Twitter poll
>>>> (https://twitter.com/jlivingood/status/1720060429311901873):
>>>> 
>>>> _______________________________________________
>>>> Nnagain mailing list
>>>> Nnagain@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>> 
>>> --
>>> 
>>> Please send any postal/overnight deliveries to:
>>> 
>>> Vint Cerf
>>> Google, LLC
>>> 1900 Reston Metro Plaza, 16th Floor
>>> Reston, VA 20190
>>> +1 (571) 213 1346
>>> 
>>> until further notice
>>> 
>>> _______________________________________________
>>> Nnagain mailing list
>>> Nnagain@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/nnagain
>> 
>> 
>> 
>> Links:
>> ------
>> [1] https://www.ietf.org/how/meetings/118/
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] [EXTERNAL] Re: FCC NOI due dec 1 on broadband speed standards

[Livingood, Jason]

[-- Attachment #1.1: Type: text/plain, Size: 845 bytes --]

> That's an unusually high ratio of up to down, so my suspicion is that they aren't time correlated; they're also not /normal/ or /evening/ peaks, I'm expecting.



I suspect the higher upstream is due to the fact that (using the Meetecho tool) each WG session is streaming live A/V to the internet (and remote and in-person participants are logged into that as well).
[A graph showing a line of yellow and green lines  Description automatically generated]





> There's a big difference between individual peaks of upload and aggregate peaks of upload; most people aren't streaming high symmetric bandwidth simultaneously. Consequently a peak busy hour online load, I'm finding, is still much more like 8:1 over all users (idle and active), in Preseem's data set.



That ratio sounds much more typical, for sure.



Jason

[-- Attachment #1.2: Type: text/html, Size: 5195 bytes --]

[-- Attachment #2: image001.png --]
[-- Type: image/png, Size: 200022 bytes --]

Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

[Jack Haverty]

[-- Attachment #1: Type: text/plain, Size: 5481 bytes --]

In the beginning days of the Arpanet, circa early 1970s, ARPA made a 
policy decision about use of the Arpanet.  First, Arpa Program Managers, 
located on the East Coast of the US, were assigned computer accounts on 
USC-ISIA, located on the West Coast in LA. Thus to do their work, 
exchanging email, editting documents, and such, they had to *use* the 
Arpanet to connect their terminals in Washington to the PDP-10 in 
California - 3000 miles away.

Second, ARPA began requiring all of their contractors (researchers at 
Universities etc.) to interact with Arpa using email and FTP. If your 
site was "on the Arpanet", you had to use the Arpanet.  If you wanted 
your proposal for next year's research to be funded, you had to submit 
your proposal using the net.

This policy caused a profound attention, by everyone involved, to making 
the Arpanet work and be useful as a collaboration tool.

JCR Licklider (aka Lick) was my advisor at MIT, and then my boss when I 
joined the Research Staff.   Lick had been at ARPA for a while, 
promoting his vision of a "Galactic Network" that resulted in the 
Arpanet as a first step.  At MIT, Lick still had need for lots of 
interactions with others.   My assignment was to build and operate the 
email system for Lick's group at MIT on our own PDP-10. Lick had a 
terminal in his office and was online a lot.   If email didn't work, I 
heard about it.   If the Arpanet didn't work, BBN heard about it.

This pressure was part of Arpa policy.   Sometimes it's referred to as 
"eating your own dog food" -- i.e., making sure your "dog" will get the 
same kind of nutrition you enjoy.   IMHO, that pressure policy was 
important, perhaps crucial, to the success of the Arpanet.

In the 70s, meetings still occurred, but a lot of progress was made 
through the use of the Arpanet.   You can only do so much with email and 
file interactions.  Today, the possibilities for far richer interactions 
are much more prevalent.   But IMHO they are held back, possibly because 
no one is feeling the pressure to "make it work". Gigabit throughputs 
are common, but why does my video and audio still break up...?

It's important to have face-to-face meetings, but perhaps if the IETF 
scheduled a future meeting to be online only, whatever needs to happen 
to make it work would happen?  Perhaps...

Even a "game" might drive progress.  At Interop '92, we resurrected the 
old "MazeWars" game using computers scattered across the show exhibit 
halls.  The engineers in the control room above the floor felt the 
pressure to make sure the Game continued to run.  At the time, the 
Internet itself was too slow for enjoyable gameplay at any distance.   
Will the Internet 30 years later work?

Or perhaps the IETF, or ISOC, or someone could take on a highly visible 
demo involving non-techie end users.   An online meeting of the UN 
General Assembly?   Or some government bodies - US Congress, British 
Parliament, etc.

Such an event would surface the issues, both technical and policy, to 
the engineers, corporations, policy-makers, and others who might have 
the ability and interest to "make it work".

Jack


On 11/14/23 10:10, Sebastian Moeller wrote:
> Hi Jack,
>
>
>> On Nov 14, 2023, at 13:02, Jack Haverty via Nnagain<nnagain@lists.bufferbloat.net>  wrote:
>>
>> If video conferencing worked well enough, they would not have to all get together in one place and would instead hold IETF meetings online ...?
> 	[SM] Turns out that humans are social creatures, and some things work better face-to-face and in the hallway (and if that is only building trust and sympathy) than over any remote technology.
>
>
>> Did anyone measure latency?   Does anyone measure throughput of "useful" traffic - e.g., excluding video/audio data that didn't arrive in time to be actually used on the screen or speaker?
> 	[SM] Utility is in the eye of the beholder, no?
>
>
>> Jack Haverty
>>
>>
>> On 11/14/23 09:25, Vint Cerf via Nnagain wrote:
>>> if they had not been all together they would have been consuming tons of video capacity doing video conference calls....
>>>
>>> :-))
>>> v
>>>
>>>
>>> On Tue, Nov 14, 2023 at 10:46 AM Livingood, Jason via Nnagain<nnagain@lists.bufferbloat.net>  wrote:
>>> On the subject of how much bandwidth does one household need, here's a fun stat for you.
>>>
>>>   
>>> At the IETF’s 118th meeting last week (Nov 4 – 10, 2023), there were over 1,000 engineers in attendance. At peak there were 870 devices connected to the WiFi network. Peak bandwidth usage:
>>>
>>> 	• Downstream peak ~750 Mbps
>>> 	• Upstream ~250 Mbps
>>>   
>>>  From my pre-meeting Twitter poll (https://twitter.com/jlivingood/status/1720060429311901873):
>>>
>>> <image001.png>
>>>
>>> _______________________________________________
>>> Nnagain mailing list
>>> Nnagain@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>
>>>
>>> -- 
>>> Please send any postal/overnight deliveries to:
>>> Vint Cerf
>>> Google, LLC
>>> 1900 Reston Metro Plaza, 16th Floor
>>> Reston, VA 20190
>>> +1 (571) 213 1346
>>>
>>>
>>> until further notice
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Nnagain mailing list
>>>
>>> Nnagain@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/nnagain
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain

[-- Attachment #2: Type: text/html, Size: 7368 bytes --]

Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

[rjmcmahon]

Thanks for sharing this. I agree this works for researchers.

I think we're at a different state and economic returns matter too.

I sent the following to our engineers in hopes we can all better 
understand what we're all trying to accomplish.

Hi All,

The attached Notice of Inquiry by the FCC shows how much our work 
matters to most everyone in our country (and, by inference, worldwide.) 
Broadband networks are no longer entertainment or social networks but 
they are critical to all regardless of gender, age, race, ethnic group, 
etc. People's health, learning, and ability to earn for their families 
all depend on us providing world class engineering to our customers who 
in turn provide these networks for each and all of us, our friends & 
families, our neighbors, and most everyone else.

Early in my career, I worked at Cisco and had the privilege to work on 
some of the first BGP routers that enabled the commercial build out of 
the internet, and I'm very thankful we did that way ahead of the 2019 
pandemic. There was no "pandemic use case" that drove us - we just 
wanted to build the best products that engineers could build. A 
worldwide pandemic w/o the internet could have been disastrous - so that 
work by many in the mid 1990s seems to have paid off well.

I hope you each realize, today, what you've accomplished since then and 
continue to be a part of. It's truly significant. It's been a high honor 
to work with so many of you over the last 14+ years.

To the FCC report:

We begin this annual inquiry in the wake of the COVID-19 pandemic during 
which time Americans increasingly turned to their broadband connections 
to conduct their lives online by using telemedicine to access 
healthcare, working from home, attending classes remotely, connecting by 
video with out-of-town family and friends, and streaming entertainment. 
Our experiences with the pandemic made it clear that broadband is no 
longer a luxury but a necessity that will only become more important 
with time. Never before has the critical importance of ensuring that all 
Americans have access to high-speed, affordable broadband been more 
evident.

Also note, we have more work to do. We need to increase resiliency as an 
example. Also, the thing I'm most passionate about is low latency. The 
FCC is now recognizing the importance of that. People are slowly 
learning why latency is becoming equally important to capacity when it 
comes to quality of service.

Bob

PS. The rest is TLDR but I thought I post some snippets for those 
interested

We believe that in examining household use cases, a simple summation of 
required speeds for individual activities may provide a misleading 
picture of actual broadband needs for at least three reasons. First, we 
believe it is appropriate to take into account at least occasional 
downloads of very large files which can be bandwidth-intensive. Second, 
it is important to account for larger households; in 2022, approximately 
21% of all U.S. households had four or more people, and the number of 
families seeking out multigenerational homes to live with additional 
relatives rose.57 Households of all sizes must have sufficient bandwidth 
to satisfy their needs. In addition, the number of connected devices per 
household continues to grow, from 18.6 in the average household in 2021 
to 20.2 in the first half of 2022.58 Taking these factors into account 
suggests that fixed broadband download/upload needs could easily exceed 
100/20 Mbps.

...

Service Quality. We recognize that other factors, besides the speed of a 
broadband connection, can affect consumers’ ability to use the services 
effectively. Chief among these factors is latency, which is the measure 
of the time it takes a packet of data to travel from one point in the 
network to another, and which is typically measured by round-trip time 
in milliseconds (ms). As a measurement of advanced telecommunications 
capability, latency can be critical because it affects a consumer’s 
ability to use real-time applications, including voice over Internet 
Protocol, video calling, distance learningapplications, and online 
gaming. Actual (as opposed to advertised) speed received, consistency of 
speed, and data allowances are also important. Such factors are not 
simply a matter of service interruptions and consumer satisfaction—they 
have a real and significant effect on Americans’ ability to use critical 
web-based applications, including those that facilitate telehealth, 
telework, and virtual learning.



> In the beginning days of the Arpanet, circa early 1970s, ARPA made a
> policy decision about use of the Arpanet.  First, Arpa Program
> Managers, located on the East Coast of the US, were assigned computer
> accounts on USC-ISIA, located on the West Coast in LA.  Thus to do
> their work, exchanging email, editting documents, and such, they had
> to *use* the Arpanet to connect their terminals in Washington to the
> PDP-10 in California - 3000 miles away.
> 
> Second, ARPA began requiring all of their contractors (researchers at
> Universities etc.) to interact with Arpa using email and FTP.   If
> your site was "on the Arpanet", you had to use the Arpanet.  If you
> wanted your proposal for next year's research to be funded, you had to
> submit your proposal using the net.
> 
> This policy caused a profound attention, by everyone involved, to
> making the Arpanet work and be useful as a collaboration tool.
> 
> JCR Licklider (aka Lick) was my advisor at MIT, and then my boss when
> I joined the Research Staff.   Lick had been at ARPA for a while,
> promoting his vision of a "Galactic Network" that resulted in the
> Arpanet as a first step.  At MIT, Lick still had need for lots of
> interactions with others.   My assignment was to build and operate the
> email system for Lick's group at MIT on our own PDP-10.  Lick had a
> terminal in his office and was online a lot.   If email didn't work, I
> heard about it.   If the Arpanet didn't work, BBN heard about it.
> 
> This pressure was part of Arpa policy.   Sometimes it's referred to as
> "eating your own dog food" -- i.e., making sure your "dog" will get
> the same kind of nutrition you enjoy.   IMHO, that pressure policy was
> important, perhaps crucial, to the success of the Arpanet.
> 
> In the 70s, meetings still occurred, but a lot of progress was made
> through the use of the Arpanet.   You can only do so much with email
> and file interactions.  Today, the possibilities for far richer
> interactions are much more prevalent.   But IMHO they are held back,
> possibly because no one is feeling the pressure to "make it work".
> Gigabit throughputs are common, but why does my video and audio still
> break up...?
> 
> It's important to have face-to-face meetings, but perhaps if the IETF
> scheduled a future meeting to be online only, whatever needs to happen
> to make it work would happen?  Perhaps...
> 
> Even a "game" might drive progress.  At Interop '92, we resurrected
> the old "MazeWars" game using computers scattered across the show
> exhibit halls.  The engineers in the control room above the floor felt
> the pressure to make sure the Game continued to run.  At the time, the
> Internet itself was too slow for enjoyable gameplay at any distance.
> Will the Internet 30 years later work?
> 
> Or perhaps the IETF, or ISOC, or someone could take on a highly
> visible demo involving non-techie end users.   An online meeting of
> the UN General Assembly?   Or some government bodies - US Congress,
> British Parliament, etc.
> 
> Such an event would surface the issues, both technical and policy, to
> the engineers, corporations, policy-makers, and others who might have
> the ability and interest to "make it work".
> 
> Jack
> 
> On 11/14/23 10:10, Sebastian Moeller wrote:
> 
>> Hi Jack,
>> 
>>> On Nov 14, 2023, at 13:02, Jack Haverty via Nnagain
>>> <nnagain@lists.bufferbloat.net> wrote:
>>> 
>>> If video conferencing worked well enough, they would not have to
>>> all get together in one place and would instead hold IETF meetings
>>> online ...?
>> 
>> [SM] Turns out that humans are social creatures, and some things
>> work better face-to-face and in the hallway (and if that is only
>> building trust and sympathy) than over any remote technology.
>> 
>>> Did anyone measure latency?   Does anyone measure throughput of
>>> "useful" traffic - e.g., excluding video/audio data that didn't
>>> arrive in time to be actually used on the screen or speaker?
>> 
>> [SM] Utility is in the eye of the beholder, no?
>> 
>> Jack Haverty
>> 
>> On 11/14/23 09:25, Vint Cerf via Nnagain wrote:
>> 
>> if they had not been all together they would have been consuming
>> tons of video capacity doing video conference calls....
>> 
>> :-))
>> v
>> 
>> On Tue, Nov 14, 2023 at 10:46 AM Livingood, Jason via Nnagain
>> <nnagain@lists.bufferbloat.net> wrote:
>> On the subject of how much bandwidth does one household need, here's
>> a fun stat for you.
>> 
>> At the IETF’s 118th meeting last week (Nov 4 – 10, 2023), there
>> were over 1,000 engineers in attendance. At peak there were 870
>> devices connected to the WiFi network. Peak bandwidth usage:
>> 
>> • Downstream peak ~750 Mbps
>> • Upstream ~250 Mbps
>> 
>> From my pre-meeting Twitter poll
>> (https://twitter.com/jlivingood/status/1720060429311901873):
>> 
>> <image001.png>
>> 
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
>> 
>> --
>> Please send any postal/overnight deliveries to:
>> Vint Cerf
>> Google, LLC
>> 1900 Reston Metro Plaza, 16th Floor
>> Reston, VA 20190
>> +1 (571) 213 1346
>> 
>> until further notice
>> 
>> _______________________________________________
>> Nnagain mailing list
>> 
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
>> 
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain

Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

[Sebastian Moeller]

[-- Attachment #1: Type: text/plain, Size: 6193 bytes --]

Hi Jack,

My argument is this is not a hard or software problem, but a wetware problem, hard to shake off million years of evolution. And IIRC during covid, didn't the IETF do online only meetings?

I am not saying video conferencing is doomed, it came a long way in the covid years and is 'here to stay', but it will only replace face to face meetings for some conditions, is all I am saying....

On 14 November 2023 14:27:28 GMT-05:00, Jack Haverty <jack@3kitty.org> wrote:
>In the beginning days of the Arpanet, circa early 1970s, ARPA made a policy decision about use of the Arpanet.  First, Arpa Program Managers, located on the East Coast of the US, were assigned computer accounts on USC-ISIA, located on the West Coast in LA. Thus to do their work, exchanging email, editting documents, and such, they had to *use* the Arpanet to connect their terminals in Washington to the PDP-10 in California - 3000 miles away.
>
>Second, ARPA began requiring all of their contractors (researchers at Universities etc.) to interact with Arpa using email and FTP. If your site was "on the Arpanet", you had to use the Arpanet.  If you wanted your proposal for next year's research to be funded, you had to submit your proposal using the net.
>
>This policy caused a profound attention, by everyone involved, to making the Arpanet work and be useful as a collaboration tool.
>
>JCR Licklider (aka Lick) was my advisor at MIT, and then my boss when I joined the Research Staff.   Lick had been at ARPA for a while, promoting his vision of a "Galactic Network" that resulted in the Arpanet as a first step.  At MIT, Lick still had need for lots of interactions with others.   My assignment was to build and operate the email system for Lick's group at MIT on our own PDP-10. Lick had a terminal in his office and was online a lot.   If email didn't work, I heard about it.   If the Arpanet didn't work, BBN heard about it.
>
>This pressure was part of Arpa policy.   Sometimes it's referred to as "eating your own dog food" -- i.e., making sure your "dog" will get the same kind of nutrition you enjoy.   IMHO, that pressure policy was important, perhaps crucial, to the success of the Arpanet.
>
>In the 70s, meetings still occurred, but a lot of progress was made through the use of the Arpanet.   You can only do so much with email and file interactions.  Today, the possibilities for far richer interactions are much more prevalent.   But IMHO they are held back, possibly because no one is feeling the pressure to "make it work". Gigabit throughputs are common, but why does my video and audio still break up...?
>
>It's important to have face-to-face meetings, but perhaps if the IETF scheduled a future meeting to be online only, whatever needs to happen to make it work would happen?  Perhaps...
>
>Even a "game" might drive progress.  At Interop '92, we resurrected the old "MazeWars" game using computers scattered across the show exhibit halls.  The engineers in the control room above the floor felt the pressure to make sure the Game continued to run.  At the time, the Internet itself was too slow for enjoyable gameplay at any distance.   Will the Internet 30 years later work?
>
>Or perhaps the IETF, or ISOC, or someone could take on a highly visible demo involving non-techie end users.   An online meeting of the UN General Assembly?   Or some government bodies - US Congress, British Parliament, etc.
>
>Such an event would surface the issues, both technical and policy, to the engineers, corporations, policy-makers, and others who might have the ability and interest to "make it work".
>
>Jack
>
>
>On 11/14/23 10:10, Sebastian Moeller wrote:
>> Hi Jack,
>> 
>> 
>>> On Nov 14, 2023, at 13:02, Jack Haverty via Nnagain<nnagain@lists.bufferbloat.net>  wrote:
>>> 
>>> If video conferencing worked well enough, they would not have to all get together in one place and would instead hold IETF meetings online ...?
>> 	[SM] Turns out that humans are social creatures, and some things work better face-to-face and in the hallway (and if that is only building trust and sympathy) than over any remote technology.
>> 
>> 
>>> Did anyone measure latency?   Does anyone measure throughput of "useful" traffic - e.g., excluding video/audio data that didn't arrive in time to be actually used on the screen or speaker?
>> 	[SM] Utility is in the eye of the beholder, no?
>> 
>> 
>>> Jack Haverty
>>> 
>>> 
>>> On 11/14/23 09:25, Vint Cerf via Nnagain wrote:
>>>> if they had not been all together they would have been consuming tons of video capacity doing video conference calls....
>>>> 
>>>> :-))
>>>> v
>>>> 
>>>> 
>>>> On Tue, Nov 14, 2023 at 10:46 AM Livingood, Jason via Nnagain<nnagain@lists.bufferbloat.net>  wrote:
>>>> On the subject of how much bandwidth does one household need, here's a fun stat for you.
>>>> 
>>>>   At the IETF’s 118th meeting last week (Nov 4 – 10, 2023), there were over 1,000 engineers in attendance. At peak there were 870 devices connected to the WiFi network. Peak bandwidth usage:
>>>> 
>>>> 	• Downstream peak ~750 Mbps
>>>> 	• Upstream ~250 Mbps
>>>>    From my pre-meeting Twitter poll (https://twitter.com/jlivingood/status/1720060429311901873):
>>>> 
>>>> <image001.png>
>>>> 
>>>> _______________________________________________
>>>> Nnagain mailing list
>>>> Nnagain@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>> 
>>>> 
>>>> -- 
>>>> Please send any postal/overnight deliveries to:
>>>> Vint Cerf
>>>> Google, LLC
>>>> 1900 Reston Metro Plaza, 16th Floor
>>>> Reston, VA 20190
>>>> +1 (571) 213 1346
>>>> 
>>>> 
>>>> until further notice
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Nnagain mailing list
>>>> 
>>>> Nnagain@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>> _______________________________________________
>>> Nnagain mailing list
>>> Nnagain@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/nnagain

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[-- Attachment #2: Type: text/html, Size: 8519 bytes --]

Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

[David Lang]

[-- Attachment #1: Type: text/plain, Size: 6561 bytes --]

It's really hard to overhear a nearby conversation that catches your interest in 
a zoom environment compared to what happens at the 'hallway track' when you are 
in-person

If all you are interested in is the session contents, then video recordings 
(possibly supplemented by the ability to ask questions) is all you need.

but good conferences offer much more than just that.

David Lang


On Tue, 14 Nov 2023, Sebastian Moeller via Nnagain wrote:

> Hi Jack,
>
> My argument is this is not a hard or software problem, but a wetware problem, hard to shake off million years of evolution. And IIRC during covid, didn't the IETF do online only meetings?
>
> I am not saying video conferencing is doomed, it came a long way in the covid years and is 'here to stay', but it will only replace face to face meetings for some conditions, is all I am saying....
>
> On 14 November 2023 14:27:28 GMT-05:00, Jack Haverty <jack@3kitty.org> wrote:
>> In the beginning days of the Arpanet, circa early 1970s, ARPA made a policy decision about use of the Arpanet.  First, Arpa Program Managers, located on the East Coast of the US, were assigned computer accounts on USC-ISIA, located on the West Coast in LA. Thus to do their work, exchanging email, editting documents, and such, they had to *use* the Arpanet to connect their terminals in Washington to the PDP-10 in California - 3000 miles away.
>>
>> Second, ARPA began requiring all of their contractors (researchers at Universities etc.) to interact with Arpa using email and FTP. If your site was "on the Arpanet", you had to use the Arpanet.  If you wanted your proposal for next year's research to be funded, you had to submit your proposal using the net.
>>
>> This policy caused a profound attention, by everyone involved, to making the Arpanet work and be useful as a collaboration tool.
>>
>> JCR Licklider (aka Lick) was my advisor at MIT, and then my boss when I joined the Research Staff.   Lick had been at ARPA for a while, promoting his vision of a "Galactic Network" that resulted in the Arpanet as a first step.  At MIT, Lick still had need for lots of interactions with others.   My assignment was to build and operate the email system for Lick's group at MIT on our own PDP-10. Lick had a terminal in his office and was online a lot.   If email didn't work, I heard about it.   If the Arpanet didn't work, BBN heard about it.
>>
>> This pressure was part of Arpa policy.   Sometimes it's referred to as "eating your own dog food" -- i.e., making sure your "dog" will get the same kind of nutrition you enjoy.   IMHO, that pressure policy was important, perhaps crucial, to the success of the Arpanet.
>>
>> In the 70s, meetings still occurred, but a lot of progress was made through the use of the Arpanet.   You can only do so much with email and file interactions.  Today, the possibilities for far richer interactions are much more prevalent.   But IMHO they are held back, possibly because no one is feeling the pressure to "make it work". Gigabit throughputs are common, but why does my video and audio still break up...?
>>
>> It's important to have face-to-face meetings, but perhaps if the IETF scheduled a future meeting to be online only, whatever needs to happen to make it work would happen?  Perhaps...
>>
>> Even a "game" might drive progress.  At Interop '92, we resurrected the old "MazeWars" game using computers scattered across the show exhibit halls.  The engineers in the control room above the floor felt the pressure to make sure the Game continued to run.  At the time, the Internet itself was too slow for enjoyable gameplay at any distance.   Will the Internet 30 years later work?
>>
>> Or perhaps the IETF, or ISOC, or someone could take on a highly visible demo involving non-techie end users.   An online meeting of the UN General Assembly?   Or some government bodies - US Congress, British Parliament, etc.
>>
>> Such an event would surface the issues, both technical and policy, to the engineers, corporations, policy-makers, and others who might have the ability and interest to "make it work".
>>
>> Jack
>>
>>
>> On 11/14/23 10:10, Sebastian Moeller wrote:
>>> Hi Jack,
>>>
>>>
>>>> On Nov 14, 2023, at 13:02, Jack Haverty via Nnagain<nnagain@lists.bufferbloat.net>  wrote:
>>>>
>>>> If video conferencing worked well enough, they would not have to all get together in one place and would instead hold IETF meetings online ...?
>>> 	[SM] Turns out that humans are social creatures, and some things work better face-to-face and in the hallway (and if that is only building trust and sympathy) than over any remote technology.
>>>
>>>
>>>> Did anyone measure latency?   Does anyone measure throughput of "useful" traffic - e.g., excluding video/audio data that didn't arrive in time to be actually used on the screen or speaker?
>>> 	[SM] Utility is in the eye of the beholder, no?
>>>
>>>
>>>> Jack Haverty
>>>>
>>>>
>>>> On 11/14/23 09:25, Vint Cerf via Nnagain wrote:
>>>>> if they had not been all together they would have been consuming tons of video capacity doing video conference calls....
>>>>>
>>>>> :-))
>>>>> v
>>>>>
>>>>>
>>>>> On Tue, Nov 14, 2023 at 10:46 AM Livingood, Jason via Nnagain<nnagain@lists.bufferbloat.net>  wrote:
>>>>> On the subject of how much bandwidth does one household need, here's a fun stat for you.
>>>>>
>>>>>   At the IETF’s 118th meeting last week (Nov 4 – 10, 2023), there were over 1,000 engineers in attendance. At peak there were 870 devices connected to the WiFi network. Peak bandwidth usage:
>>>>>
>>>>> 	• Downstream peak ~750 Mbps
>>>>> 	• Upstream ~250 Mbps
>>>>>    From my pre-meeting Twitter poll (https://twitter.com/jlivingood/status/1720060429311901873):
>>>>>
>>>>> <image001.png>
>>>>>
>>>>> _______________________________________________
>>>>> Nnagain mailing list
>>>>> Nnagain@lists.bufferbloat.net
>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>>>
>>>>>
>>>>> --
>>>>> Please send any postal/overnight deliveries to:
>>>>> Vint Cerf
>>>>> Google, LLC
>>>>> 1900 Reston Metro Plaza, 16th Floor
>>>>> Reston, VA 20190
>>>>> +1 (571) 213 1346
>>>>>
>>>>>
>>>>> until further notice
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Nnagain mailing list
>>>>>
>>>>> Nnagain@lists.bufferbloat.net
>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>> _______________________________________________
>>>> Nnagain mailing list
>>>> Nnagain@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/nnagain
>
>

Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

[Dick Roy]

Stanford did a study a number of years ago on how information is conveyed between humans.  How much of the information conveyed is contained in the words that are spoken???    Answer ... less than 20%.  That alone explains why F2F is sooooooo important ... 

-----Original Message-----
From: Nnagain [mailto:nnagain-bounces@lists.bufferbloat.net] On Behalf Of David Lang via Nnagain
Sent: Tuesday, November 14, 2023 12:01 PM
To: Sebastian Moeller via Nnagain
Cc: David Lang
Subject: Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

It's really hard to overhear a nearby conversation that catches your interest in 
a zoom environment compared to what happens at the 'hallway track' when you are 
in-person

If all you are interested in is the session contents, then video recordings 
(possibly supplemented by the ability to ask questions) is all you need.

but good conferences offer much more than just that.

David Lang


On Tue, 14 Nov 2023, Sebastian Moeller via Nnagain wrote:

> Hi Jack,
>
> My argument is this is not a hard or software problem, but a wetware problem, hard to shake off million years of evolution. And IIRC during covid, didn't the IETF do online only meetings?
>
> I am not saying video conferencing is doomed, it came a long way in the covid years and is 'here to stay', but it will only replace face to face meetings for some conditions, is all I am saying....
>
> On 14 November 2023 14:27:28 GMT-05:00, Jack Haverty <jack@3kitty.org> wrote:
>> In the beginning days of the Arpanet, circa early 1970s, ARPA made a policy decision about use of the Arpanet.  First, Arpa Program Managers, located on the East Coast of the US, were assigned computer accounts on USC-ISIA, located on the West Coast in LA. Thus to do their work, exchanging email, editting documents, and such, they had to *use* the Arpanet to connect their terminals in Washington to the PDP-10 in California - 3000 miles away.
>>
>> Second, ARPA began requiring all of their contractors (researchers at Universities etc.) to interact with Arpa using email and FTP. If your site was "on the Arpanet", you had to use the Arpanet.  If you wanted your proposal for next year's research to be funded, you had to submit your proposal using the net.
>>
>> This policy caused a profound attention, by everyone involved, to making the Arpanet work and be useful as a collaboration tool.
>>
>> JCR Licklider (aka Lick) was my advisor at MIT, and then my boss when I joined the Research Staff.   Lick had been at ARPA for a while, promoting his vision of a "Galactic Network" that resulted in the Arpanet as a first step.  At MIT, Lick still had need for lots of interactions with others.   My assignment was to build and operate the email system for Lick's group at MIT on our own PDP-10. Lick had a terminal in his office and was online a lot.   If email didn't work, I heard about it.   If the Arpanet didn't work, BBN heard about it.
>>
>> This pressure was part of Arpa policy.   Sometimes it's referred to as "eating your own dog food" -- i.e., making sure your "dog" will get the same kind of nutrition you enjoy.   IMHO, that pressure policy was important, perhaps crucial, to the success of the Arpanet.
>>
>> In the 70s, meetings still occurred, but a lot of progress was made through the use of the Arpanet.   You can only do so much with email and file interactions.  Today, the possibilities for far richer interactions are much more prevalent.   But IMHO they are held back, possibly because no one is feeling the pressure to "make it work". Gigabit throughputs are common, but why does my video and audio still break up...?
>>
>> It's important to have face-to-face meetings, but perhaps if the IETF scheduled a future meeting to be online only, whatever needs to happen to make it work would happen?  Perhaps...
>>
>> Even a "game" might drive progress.  At Interop '92, we resurrected the old "MazeWars" game using computers scattered across the show exhibit halls.  The engineers in the control room above the floor felt the pressure to make sure the Game continued to run.  At the time, the Internet itself was too slow for enjoyable gameplay at any distance.   Will the Internet 30 years later work?
>>
>> Or perhaps the IETF, or ISOC, or someone could take on a highly visible demo involving non-techie end users.   An online meeting of the UN General Assembly?   Or some government bodies - US Congress, British Parliament, etc.
>>
>> Such an event would surface the issues, both technical and policy, to the engineers, corporations, policy-makers, and others who might have the ability and interest to "make it work".
>>
>> Jack
>>
>>
>> On 11/14/23 10:10, Sebastian Moeller wrote:
>>> Hi Jack,
>>>
>>>
>>>> On Nov 14, 2023, at 13:02, Jack Haverty via Nnagain<nnagain@lists.bufferbloat.net>  wrote:
>>>>
>>>> If video conferencing worked well enough, they would not have to all get together in one place and would instead hold IETF meetings online ...?
>>> 	[SM] Turns out that humans are social creatures, and some things work better face-to-face and in the hallway (and if that is only building trust and sympathy) than over any remote technology.
>>>
>>>
>>>> Did anyone measure latency?   Does anyone measure throughput of "useful" traffic - e.g., excluding video/audio data that didn't arrive in time to be actually used on the screen or speaker?
>>> 	[SM] Utility is in the eye of the beholder, no?
>>>
>>>
>>>> Jack Haverty
>>>>
>>>>
>>>> On 11/14/23 09:25, Vint Cerf via Nnagain wrote:
>>>>> if they had not been all together they would have been consuming tons of video capacity doing video conference calls....
>>>>>
>>>>> :-))
>>>>> v
>>>>>
>>>>>
>>>>> On Tue, Nov 14, 2023 at 10:46 AM Livingood, Jason via Nnagain<nnagain@lists.bufferbloat.net>  wrote:
>>>>> On the subject of how much bandwidth does one household need, here's a fun stat for you.
>>>>>
>>>>>   At the IETF’s 118th meeting last week (Nov 4 – 10, 2023), there were over 1,000 engineers in attendance. At peak there were 870 devices connected to the WiFi network. Peak bandwidth usage:
>>>>>
>>>>> 	• Downstream peak ~750 Mbps
>>>>> 	• Upstream ~250 Mbps
>>>>>    From my pre-meeting Twitter poll (https://twitter.com/jlivingood/status/1720060429311901873):
>>>>>
>>>>> <image001.png>
>>>>>
>>>>> _______________________________________________
>>>>> Nnagain mailing list
>>>>> Nnagain@lists.bufferbloat.net
>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>>>
>>>>>
>>>>> --
>>>>> Please send any postal/overnight deliveries to:
>>>>> Vint Cerf
>>>>> Google, LLC
>>>>> 1900 Reston Metro Plaza, 16th Floor
>>>>> Reston, VA 20190
>>>>> +1 (571) 213 1346
>>>>>
>>>>>
>>>>> until further notice
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Nnagain mailing list
>>>>>
>>>>> Nnagain@lists.bufferbloat.net
>>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>> _______________________________________________
>>>> Nnagain mailing list
>>>> Nnagain@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/nnagain
>
>

Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

[Livingood, Jason]

[-- Attachment #1: Type: text/plain, Size: 1548 bytes --]

> And IIRC during covid, didn't the IETF do online only meetings?

Yes, we did! The IETF pivoted in March 2020 to fully virtual with 701 remote attendees. That continued for 2 years until March 2022 when we started having in-person again – and since that time they have been hybrid (and will continue to be so). The IETF also invested quite a lot in online meeting tools<https://www.ietf.org/how/meetings/technology/meetecho-guide-participant/> & supporting systems to try to make the remote experience as good as possible.

IETF 118
November 04-10, 2023, Prague, Czech Republic & Online
1067 onsite attendees
739 remote attendees

IETF 117
July 22-28, 2023, San Francisco, California & Online
890 onsite attendees
544 remote attendees

IETF 116
March 25-31, 2023, Yokohama, Japan & Online
993 onsite attendees
594 remote attendees

IETF 115
November 5-11, 2022, London, UK & Online
849 onsite attendees
667 remote attendees

IETF 114
July 23-29, 2022, Philadelphia, Pennsylvania & Online
618 onsite attendees
675 remote attendees

IETF 113
March 19-25, 2022, Vienna, Austria & Online
314 onsite attendees
976 remote attendees

IETF 112
November 08-12, 2021, Online
1177 remote attendees

IETF 111
July 26-30, 2021, Online
1206 remote attendees

IETF 110
March 8-12, 2021, Online
1177 remote attendees

IETF 109
November 16-20, 2020, Online
1061 remote attendees

IETF 108
July 27-31, 2020, Online
1102 remote attendees

IETF 107
March 23-27, 2020, Virtual
701 remote attendees

//end//

[-- Attachment #2: Type: text/html, Size: 7396 bytes --]

[NNagain] Virtual mtgs and conferences vs. in-person ones (was) Re: FCC NOI due dec 1 on broadband speed standards

[David Bray, PhD]

[-- Attachment #1: Type: text/plain, Size: 9630 bytes --]

Also a recent Nature study - audio conversations are better at creative
brainstorms and ideation then audio+video (over whatever video platform of
choice). Aside from the empirical findings, the proposed reason why is
video has people's brains trying to make sense of a non-life sized images
of talking heads presented to us in ways that our historical evolutionary
experiences is going "WTF?" at the subconscious and unconscious levels.

There's even some evidence that 2D flat videos actually have the body in a
continuous state of alertness for a potential threat - again because our
brains are trying to figure out whether these non-life sized images of
talking heads are a threat or not? (Stay tuned if there's ever a lawsuit
against an employer for forcing employees to endure too many streaming
video meetings).


Virtual communication curbs creative idea generation

https://www.nature.com/articles/s41586-022-04643-y

*In a laboratory study and a field experiment across five countries (in
Europe, the Middle East and South Asia), we show that videoconferencing
inhibits the production of creative ideas. *

[But also]

*By contrast, when it comes to selecting which idea to pursue, we find no
evidence that videoconferencing groups are less effective (and preliminary
evidence that they may be more effective) than in-person groups. *

[And finally]

*Specifically, using eye-gaze and recall measures, as well as latent
semantic analysis, we demonstrate that videoconferencing hampers idea
generation because it focuses communicators on a screen, which prompts a
narrower cognitive focus. Our results suggest that virtual interaction
comes with a cognitive cost for creative idea generation.*



On Tue, Nov 14, 2023 at 3:37 PM Dick Roy via Nnagain <
nnagain@lists.bufferbloat.net> wrote:

> Stanford did a study a number of years ago on how information is conveyed
> between humans.  How much of the information conveyed is contained in the
> words that are spoken???    Answer ... less than 20%.  That alone explains
> why F2F is sooooooo important ...
>
> -----Original Message-----
> From: Nnagain [mailto:nnagain-bounces@lists.bufferbloat.net] On Behalf Of
> David Lang via Nnagain
> Sent: Tuesday, November 14, 2023 12:01 PM
> To: Sebastian Moeller via Nnagain
> Cc: David Lang
> Subject: Re: [NNagain] FCC NOI due dec 1 on broadband speed standards
>
> It's really hard to overhear a nearby conversation that catches your
> interest in
> a zoom environment compared to what happens at the 'hallway track' when
> you are
> in-person
>
> If all you are interested in is the session contents, then video
> recordings
> (possibly supplemented by the ability to ask questions) is all you need.
>
> but good conferences offer much more than just that.
>
> David Lang
>
>
> On Tue, 14 Nov 2023, Sebastian Moeller via Nnagain wrote:
>
> > Hi Jack,
> >
> > My argument is this is not a hard or software problem, but a wetware
> problem, hard to shake off million years of evolution. And IIRC during
> covid, didn't the IETF do online only meetings?
> >
> > I am not saying video conferencing is doomed, it came a long way in the
> covid years and is 'here to stay', but it will only replace face to face
> meetings for some conditions, is all I am saying....
> >
> > On 14 November 2023 14:27:28 GMT-05:00, Jack Haverty <jack@3kitty.org>
> wrote:
> >> In the beginning days of the Arpanet, circa early 1970s, ARPA made a
> policy decision about use of the Arpanet.  First, Arpa Program Managers,
> located on the East Coast of the US, were assigned computer accounts on
> USC-ISIA, located on the West Coast in LA. Thus to do their work,
> exchanging email, editting documents, and such, they had to *use* the
> Arpanet to connect their terminals in Washington to the PDP-10 in
> California - 3000 miles away.
> >>
> >> Second, ARPA began requiring all of their contractors (researchers at
> Universities etc.) to interact with Arpa using email and FTP. If your site
> was "on the Arpanet", you had to use the Arpanet.  If you wanted your
> proposal for next year's research to be funded, you had to submit your
> proposal using the net.
> >>
> >> This policy caused a profound attention, by everyone involved, to
> making the Arpanet work and be useful as a collaboration tool.
> >>
> >> JCR Licklider (aka Lick) was my advisor at MIT, and then my boss when I
> joined the Research Staff.   Lick had been at ARPA for a while, promoting
> his vision of a "Galactic Network" that resulted in the Arpanet as a first
> step.  At MIT, Lick still had need for lots of interactions with others.
>  My assignment was to build and operate the email system for Lick's group
> at MIT on our own PDP-10. Lick had a terminal in his office and was online
> a lot.   If email didn't work, I heard about it.   If the Arpanet didn't
> work, BBN heard about it.
> >>
> >> This pressure was part of Arpa policy.   Sometimes it's referred to as
> "eating your own dog food" -- i.e., making sure your "dog" will get the
> same kind of nutrition you enjoy.   IMHO, that pressure policy was
> important, perhaps crucial, to the success of the Arpanet.
> >>
> >> In the 70s, meetings still occurred, but a lot of progress was made
> through the use of the Arpanet.   You can only do so much with email and
> file interactions.  Today, the possibilities for far richer interactions
> are much more prevalent.   But IMHO they are held back, possibly because no
> one is feeling the pressure to "make it work". Gigabit throughputs are
> common, but why does my video and audio still break up...?
> >>
> >> It's important to have face-to-face meetings, but perhaps if the IETF
> scheduled a future meeting to be online only, whatever needs to happen to
> make it work would happen?  Perhaps...
> >>
> >> Even a "game" might drive progress.  At Interop '92, we resurrected the
> old "MazeWars" game using computers scattered across the show exhibit
> halls.  The engineers in the control room above the floor felt the pressure
> to make sure the Game continued to run.  At the time, the Internet itself
> was too slow for enjoyable gameplay at any distance.   Will the Internet 30
> years later work?
> >>
> >> Or perhaps the IETF, or ISOC, or someone could take on a highly visible
> demo involving non-techie end users.   An online meeting of the UN General
> Assembly?   Or some government bodies - US Congress, British Parliament,
> etc.
> >>
> >> Such an event would surface the issues, both technical and policy, to
> the engineers, corporations, policy-makers, and others who might have the
> ability and interest to "make it work".
> >>
> >> Jack
> >>
> >>
> >> On 11/14/23 10:10, Sebastian Moeller wrote:
> >>> Hi Jack,
> >>>
> >>>
> >>>> On Nov 14, 2023, at 13:02, Jack Haverty via Nnagain<
> nnagain@lists.bufferbloat.net>  wrote:
> >>>>
> >>>> If video conferencing worked well enough, they would not have to all
> get together in one place and would instead hold IETF meetings online ...?
> >>>     [SM] Turns out that humans are social creatures, and some things
> work better face-to-face and in the hallway (and if that is only building
> trust and sympathy) than over any remote technology.
> >>>
> >>>
> >>>> Did anyone measure latency?   Does anyone measure throughput of
> "useful" traffic - e.g., excluding video/audio data that didn't arrive in
> time to be actually used on the screen or speaker?
> >>>     [SM] Utility is in the eye of the beholder, no?
> >>>
> >>>
> >>>> Jack Haverty
> >>>>
> >>>>
> >>>> On 11/14/23 09:25, Vint Cerf via Nnagain wrote:
> >>>>> if they had not been all together they would have been consuming
> tons of video capacity doing video conference calls....
> >>>>>
> >>>>> :-))
> >>>>> v
> >>>>>
> >>>>>
> >>>>> On Tue, Nov 14, 2023 at 10:46 AM Livingood, Jason via Nnagain<
> nnagain@lists.bufferbloat.net>  wrote:
> >>>>> On the subject of how much bandwidth does one household need, here's
> a fun stat for you.
> >>>>>
> >>>>>   At the IETF’s 118th meeting last week (Nov 4 – 10, 2023), there
> were over 1,000 engineers in attendance. At peak there were 870 devices
> connected to the WiFi network. Peak bandwidth usage:
> >>>>>
> >>>>>   • Downstream peak ~750 Mbps
> >>>>>   • Upstream ~250 Mbps
> >>>>>    From my pre-meeting Twitter poll (
> https://twitter.com/jlivingood/status/1720060429311901873):
> >>>>>
> >>>>> <image001.png>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Nnagain mailing list
> >>>>> Nnagain@lists.bufferbloat.net
> >>>>> https://lists.bufferbloat.net/listinfo/nnagain
> >>>>>
> >>>>>
> >>>>> --
> >>>>> Please send any postal/overnight deliveries to:
> >>>>> Vint Cerf
> >>>>> Google, LLC
> >>>>> 1900 Reston Metro Plaza, 16th Floor
> >>>>> Reston, VA 20190
> >>>>> +1 (571) 213 1346
> >>>>>
> >>>>>
> >>>>> until further notice
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Nnagain mailing list
> >>>>>
> >>>>> Nnagain@lists.bufferbloat.net
> >>>>> https://lists.bufferbloat.net/listinfo/nnagain
> >>>> _______________________________________________
> >>>> Nnagain mailing list
> >>>> Nnagain@lists.bufferbloat.net
> >>>> https://lists.bufferbloat.net/listinfo/nnagain
> >
> >
>
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain
>

[-- Attachment #2: Type: text/html, Size: 12795 bytes --]

Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

[Dave Taht]

I am glad you are reaching out, but it may be difficult for us to do a
joint filing.

In particular I question the seeming assumption that more wifi devices
will drive demand for more bandwidth,
and extrapolating from 18 devices forward may also well be a trend
that will reverse completely in favor of more bluetooth and thread
implementations from phone to device.

Of those 20 wifi devices today are probably

1 or more laptops
1 or more tablets
1 or more phones
1 or more tvs

and of those usually only one will be active per person, while they
are in the home, and even then....as one semi-hard number, even at
peak hours (with the libreqos data I have), only 1/6th of households
are watching video, and very, very few, more than one stream at the
same time.

The steady upload bandwidth pumpers are primarily video surveillance
devices (which as a personal preference I would prefer remain in the
home unless otherwise activated). I do not presently know much about
the frame rates or real bandwidth requirements of popular devices like
ring, etc.  Similarly I am biased towards "Babycams" sending video
from up to downstairs only and not into the cloud. I know I am bucking
the trend on this, but it will make me skeptical of much "data" that
exists today on it.

Then you have loads of extremely low bandwidth devices - alexa and
other automation is measured in bits/ms, light switches, a couple bits
a day, audio streaming 128kbit/s (when you use it). Automatic updates
to phones and tablets, etc, take place entirely asynchronously
nowadays and do not need much bandwidth. A small business just needs
to
*reliably* clear credit card transactions every few minutes.

Perhaps the biggest steady-state bandwidth suck is home gaming
updates, but while a big market, if you haven't noticed birthrates are
down, and immigration being canceled.

Thus I feel that the opposite number of 70-80% two people or less per
household  that you are not optimizing for, dominates the curves.

Looking at the actual useage disparity (delta) between fiber'd cities
and rural, uptake of passive video streaming services vs spotify,
would give me a more pessimistic projection than most. Regrettably I
lack the time and as few fund accurate scenarios, I would merely be
willing to write down my estimate and find some sort of online
"futures" market to place puts on.

Lastly, a goodly percentage of the people I know just need food,
shelter, a job and a phone, and with broadband costs skyrocketing,
aside from the gaming market and business, that is all they can
afford, even with ACP.  And all that they need. Nobody has a landline
anymore, and if it weren't for "Tv", few would want broadband at even
25/10.


On Tue, Nov 14, 2023 at 2:40 PM rjmcmahon via Nnagain
<nnagain@lists.bufferbloat.net> wrote:
>
> Thanks for sharing this. I agree this works for researchers.
>
> I think we're at a different state and economic returns matter too.
>
> I sent the following to our engineers in hopes we can all better
> understand what we're all trying to accomplish.
>
> Hi All,
>
> The attached Notice of Inquiry by the FCC shows how much our work
> matters to most everyone in our country (and, by inference, worldwide.)
> Broadband networks are no longer entertainment or social networks but
> they are critical to all regardless of gender, age, race, ethnic group,
> etc. People's health, learning, and ability to earn for their families
> all depend on us providing world class engineering to our customers who
> in turn provide these networks for each and all of us, our friends &
> families, our neighbors, and most everyone else.
>
> Early in my career, I worked at Cisco and had the privilege to work on
> some of the first BGP routers that enabled the commercial build out of
> the internet, and I'm very thankful we did that way ahead of the 2019
> pandemic. There was no "pandemic use case" that drove us - we just
> wanted to build the best products that engineers could build. A
> worldwide pandemic w/o the internet could have been disastrous - so that
> work by many in the mid 1990s seems to have paid off well.
>
> I hope you each realize, today, what you've accomplished since then and
> continue to be a part of. It's truly significant. It's been a high honor
> to work with so many of you over the last 14+ years.

This is beautiful, btw. I feel much the same way about linux being now
so used heavily in the space program,
and all our code, and hardware, that will propagate across the solar
system, and of the millions of people, that contributed to it.

> To the FCC report:
>
> We begin this annual inquiry in the wake of the COVID-19 pandemic during
> which time Americans increasingly turned to their broadband connections
> to conduct their lives online by using telemedicine to access
> healthcare, working from home, attending classes remotely, connecting by
> video with out-of-town family and friends, and streaming entertainment.
> Our experiences with the pandemic made it clear that broadband is no
> longer a luxury but a necessity that will only become more important
> with time. Never before has the critical importance of ensuring that all
> Americans have access to high-speed, affordable broadband been more
> evident.
>
> Also note, we have more work to do. We need to increase resiliency as an
> example. Also, the thing I'm most passionate about is low latency. The
> FCC is now recognizing the importance of that. People are slowly
> learning why latency is becoming equally important to capacity when it
> comes to quality of service.
>
> Bob
>
> PS. The rest is TLDR but I thought I post some snippets for those
> interested
>
> We believe that in examining household use cases, a simple summation of
> required speeds for individual activities may provide a misleading
> picture of actual broadband needs for at least three reasons. First, we
> believe it is appropriate to take into account at least occasional
> downloads of very large files which can be bandwidth-intensive. Second,
> it is important to account for larger households; in 2022, approximately
> 21% of all U.S. households had four or more people, and the number of
> families seeking out multigenerational homes to live with additional
> relatives rose.57 Households of all sizes must have sufficient bandwidth
> to satisfy their needs. In addition, the number of connected devices per
> household continues to grow, from 18.6 in the average household in 2021
> to 20.2 in the first half of 2022.58 Taking these factors into account
> suggests that fixed broadband download/upload needs could easily exceed
> 100/20 Mbps.
>
> ...
>
> Service Quality. We recognize that other factors, besides the speed of a
> broadband connection, can affect consumers’ ability to use the services
> effectively. Chief among these factors is latency, which is the measure
> of the time it takes a packet of data to travel from one point in the
> network to another, and which is typically measured by round-trip time
> in milliseconds (ms). As a measurement of advanced telecommunications
> capability, latency can be critical because it affects a consumer’s
> ability to use real-time applications, including voice over Internet
> Protocol, video calling, distance learningapplications, and online
> gaming. Actual (as opposed to advertised) speed received, consistency of
> speed, and data allowances are also important. Such factors are not
> simply a matter of service interruptions and consumer satisfaction—they
> have a real and significant effect on Americans’ ability to use critical
> web-based applications, including those that facilitate telehealth,
> telework, and virtual learning.
>
>
>
> > In the beginning days of the Arpanet, circa early 1970s, ARPA made a
> > policy decision about use of the Arpanet.  First, Arpa Program
> > Managers, located on the East Coast of the US, were assigned computer
> > accounts on USC-ISIA, located on the West Coast in LA.  Thus to do
> > their work, exchanging email, editting documents, and such, they had
> > to *use* the Arpanet to connect their terminals in Washington to the
> > PDP-10 in California - 3000 miles away.
> >
> > Second, ARPA began requiring all of their contractors (researchers at
> > Universities etc.) to interact with Arpa using email and FTP.   If
> > your site was "on the Arpanet", you had to use the Arpanet.  If you
> > wanted your proposal for next year's research to be funded, you had to
> > submit your proposal using the net.
> >
> > This policy caused a profound attention, by everyone involved, to
> > making the Arpanet work and be useful as a collaboration tool.
> >
> > JCR Licklider (aka Lick) was my advisor at MIT, and then my boss when
> > I joined the Research Staff.   Lick had been at ARPA for a while,
> > promoting his vision of a "Galactic Network" that resulted in the
> > Arpanet as a first step.  At MIT, Lick still had need for lots of
> > interactions with others.   My assignment was to build and operate the
> > email system for Lick's group at MIT on our own PDP-10.  Lick had a
> > terminal in his office and was online a lot.   If email didn't work, I
> > heard about it.   If the Arpanet didn't work, BBN heard about it.
> >
> > This pressure was part of Arpa policy.   Sometimes it's referred to as
> > "eating your own dog food" -- i.e., making sure your "dog" will get
> > the same kind of nutrition you enjoy.   IMHO, that pressure policy was
> > important, perhaps crucial, to the success of the Arpanet.
> >
> > In the 70s, meetings still occurred, but a lot of progress was made
> > through the use of the Arpanet.   You can only do so much with email
> > and file interactions.  Today, the possibilities for far richer
> > interactions are much more prevalent.   But IMHO they are held back,
> > possibly because no one is feeling the pressure to "make it work".
> > Gigabit throughputs are common, but why does my video and audio still
> > break up...?
> >
> > It's important to have face-to-face meetings, but perhaps if the IETF
> > scheduled a future meeting to be online only, whatever needs to happen
> > to make it work would happen?  Perhaps...
> >
> > Even a "game" might drive progress.  At Interop '92, we resurrected
> > the old "MazeWars" game using computers scattered across the show
> > exhibit halls.  The engineers in the control room above the floor felt
> > the pressure to make sure the Game continued to run.  At the time, the
> > Internet itself was too slow for enjoyable gameplay at any distance.
> > Will the Internet 30 years later work?
> >
> > Or perhaps the IETF, or ISOC, or someone could take on a highly
> > visible demo involving non-techie end users.   An online meeting of
> > the UN General Assembly?   Or some government bodies - US Congress,
> > British Parliament, etc.
> >
> > Such an event would surface the issues, both technical and policy, to
> > the engineers, corporations, policy-makers, and others who might have
> > the ability and interest to "make it work".
> >
> > Jack
> >
> > On 11/14/23 10:10, Sebastian Moeller wrote:
> >
> >> Hi Jack,
> >>
> >>> On Nov 14, 2023, at 13:02, Jack Haverty via Nnagain
> >>> <nnagain@lists.bufferbloat.net> wrote:
> >>>
> >>> If video conferencing worked well enough, they would not have to
> >>> all get together in one place and would instead hold IETF meetings
> >>> online ...?
> >>
> >> [SM] Turns out that humans are social creatures, and some things
> >> work better face-to-face and in the hallway (and if that is only
> >> building trust and sympathy) than over any remote technology.
> >>
> >>> Did anyone measure latency?   Does anyone measure throughput of
> >>> "useful" traffic - e.g., excluding video/audio data that didn't
> >>> arrive in time to be actually used on the screen or speaker?
> >>
> >> [SM] Utility is in the eye of the beholder, no?
> >>
> >> Jack Haverty
> >>
> >> On 11/14/23 09:25, Vint Cerf via Nnagain wrote:
> >>
> >> if they had not been all together they would have been consuming
> >> tons of video capacity doing video conference calls....
> >>
> >> :-))
> >> v
> >>
> >> On Tue, Nov 14, 2023 at 10:46 AM Livingood, Jason via Nnagain
> >> <nnagain@lists.bufferbloat.net> wrote:
> >> On the subject of how much bandwidth does one household need, here's
> >> a fun stat for you.
> >>
> >> At the IETF’s 118th meeting last week (Nov 4 – 10, 2023), there
> >> were over 1,000 engineers in attendance. At peak there were 870
> >> devices connected to the WiFi network. Peak bandwidth usage:
> >>
> >> • Downstream peak ~750 Mbps
> >> • Upstream ~250 Mbps
> >>
> >> From my pre-meeting Twitter poll
> >> (https://twitter.com/jlivingood/status/1720060429311901873):
> >>
> >> <image001.png>
> >>
> >> _______________________________________________
> >> Nnagain mailing list
> >> Nnagain@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/nnagain
> >>
> >> --
> >> Please send any postal/overnight deliveries to:
> >> Vint Cerf
> >> Google, LLC
> >> 1900 Reston Metro Plaza, 16th Floor
> >> Reston, VA 20190
> >> +1 (571) 213 1346
> >>
> >> until further notice
> >>
> >> _______________________________________________
> >> Nnagain mailing list
> >>
> >> Nnagain@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/nnagain
> >>
> >> _______________________________________________
> >> Nnagain mailing list
> >> Nnagain@lists.bufferbloat.net
> >> https://lists.bufferbloat.net/listinfo/nnagain
> > _______________________________________________
> > Nnagain mailing list
> > Nnagain@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/nnagain
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain



-- 
:( My old R&D campus is up for sale: https://tinyurl.com/yurtlab
Dave Täht CSO, LibreQos

Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

[rjmcmahon]

[-- Attachment #1: Type: text/plain, Size: 14720 bytes --]

I think the missing metrics & test vectors are around latency more than 
bandwidth.

I've attached a WiFi low latency table. Feel free to comment.

Good metrics could allow for a comprehensive analysis, at least from a 
WiFi perspective.

Latency under load is a good start, but likely not enough.

Bob

PS. Agreed, the digital transition with storage has many engineers who 
have contributed over decades. I'm very grateful to all of them.

> I am glad you are reaching out, but it may be difficult for us to do a
> joint filing.
> 
> In particular I question the seeming assumption that more wifi devices
> will drive demand for more bandwidth,
> and extrapolating from 18 devices forward may also well be a trend
> that will reverse completely in favor of more bluetooth and thread
> implementations from phone to device.
> 
> Of those 20 wifi devices today are probably
> 
> 1 or more laptops
> 1 or more tablets
> 1 or more phones
> 1 or more tvs
> 
> and of those usually only one will be active per person, while they
> are in the home, and even then....as one semi-hard number, even at
> peak hours (with the libreqos data I have), only 1/6th of households
> are watching video, and very, very few, more than one stream at the
> same time.
> 
> The steady upload bandwidth pumpers are primarily video surveillance
> devices (which as a personal preference I would prefer remain in the
> home unless otherwise activated). I do not presently know much about
> the frame rates or real bandwidth requirements of popular devices like
> ring, etc.  Similarly I am biased towards "Babycams" sending video
> from up to downstairs only and not into the cloud. I know I am bucking
> the trend on this, but it will make me skeptical of much "data" that
> exists today on it.
> 
> Then you have loads of extremely low bandwidth devices - alexa and
> other automation is measured in bits/ms, light switches, a couple bits
> a day, audio streaming 128kbit/s (when you use it). Automatic updates
> to phones and tablets, etc, take place entirely asynchronously
> nowadays and do not need much bandwidth. A small business just needs
> to
> *reliably* clear credit card transactions every few minutes.
> 
> Perhaps the biggest steady-state bandwidth suck is home gaming
> updates, but while a big market, if you haven't noticed birthrates are
> down, and immigration being canceled.
> 
> Thus I feel that the opposite number of 70-80% two people or less per
> household  that you are not optimizing for, dominates the curves.
> 
> Looking at the actual useage disparity (delta) between fiber'd cities
> and rural, uptake of passive video streaming services vs spotify,
> would give me a more pessimistic projection than most. Regrettably I
> lack the time and as few fund accurate scenarios, I would merely be
> willing to write down my estimate and find some sort of online
> "futures" market to place puts on.
> 
> Lastly, a goodly percentage of the people I know just need food,
> shelter, a job and a phone, and with broadband costs skyrocketing,
> aside from the gaming market and business, that is all they can
> afford, even with ACP.  And all that they need. Nobody has a landline
> anymore, and if it weren't for "Tv", few would want broadband at even
> 25/10.
> 
> 
> On Tue, Nov 14, 2023 at 2:40 PM rjmcmahon via Nnagain
> <nnagain@lists.bufferbloat.net> wrote:
>> 
>> Thanks for sharing this. I agree this works for researchers.
>> 
>> I think we're at a different state and economic returns matter too.
>> 
>> I sent the following to our engineers in hopes we can all better
>> understand what we're all trying to accomplish.
>> 
>> Hi All,
>> 
>> The attached Notice of Inquiry by the FCC shows how much our work
>> matters to most everyone in our country (and, by inference, 
>> worldwide.)
>> Broadband networks are no longer entertainment or social networks but
>> they are critical to all regardless of gender, age, race, ethnic 
>> group,
>> etc. People's health, learning, and ability to earn for their families
>> all depend on us providing world class engineering to our customers 
>> who
>> in turn provide these networks for each and all of us, our friends &
>> families, our neighbors, and most everyone else.
>> 
>> Early in my career, I worked at Cisco and had the privilege to work on
>> some of the first BGP routers that enabled the commercial build out of
>> the internet, and I'm very thankful we did that way ahead of the 2019
>> pandemic. There was no "pandemic use case" that drove us - we just
>> wanted to build the best products that engineers could build. A
>> worldwide pandemic w/o the internet could have been disastrous - so 
>> that
>> work by many in the mid 1990s seems to have paid off well.
>> 
>> I hope you each realize, today, what you've accomplished since then 
>> and
>> continue to be a part of. It's truly significant. It's been a high 
>> honor
>> to work with so many of you over the last 14+ years.
> 
> This is beautiful, btw. I feel much the same way about linux being now
> so used heavily in the space program,
> and all our code, and hardware, that will propagate across the solar
> system, and of the millions of people, that contributed to it.
> 
>> To the FCC report:
>> 
>> We begin this annual inquiry in the wake of the COVID-19 pandemic 
>> during
>> which time Americans increasingly turned to their broadband 
>> connections
>> to conduct their lives online by using telemedicine to access
>> healthcare, working from home, attending classes remotely, connecting 
>> by
>> video with out-of-town family and friends, and streaming 
>> entertainment.
>> Our experiences with the pandemic made it clear that broadband is no
>> longer a luxury but a necessity that will only become more important
>> with time. Never before has the critical importance of ensuring that 
>> all
>> Americans have access to high-speed, affordable broadband been more
>> evident.
>> 
>> Also note, we have more work to do. We need to increase resiliency as 
>> an
>> example. Also, the thing I'm most passionate about is low latency. The
>> FCC is now recognizing the importance of that. People are slowly
>> learning why latency is becoming equally important to capacity when it
>> comes to quality of service.
>> 
>> Bob
>> 
>> PS. The rest is TLDR but I thought I post some snippets for those
>> interested
>> 
>> We believe that in examining household use cases, a simple summation 
>> of
>> required speeds for individual activities may provide a misleading
>> picture of actual broadband needs for at least three reasons. First, 
>> we
>> believe it is appropriate to take into account at least occasional
>> downloads of very large files which can be bandwidth-intensive. 
>> Second,
>> it is important to account for larger households; in 2022, 
>> approximately
>> 21% of all U.S. households had four or more people, and the number of
>> families seeking out multigenerational homes to live with additional
>> relatives rose.57 Households of all sizes must have sufficient 
>> bandwidth
>> to satisfy their needs. In addition, the number of connected devices 
>> per
>> household continues to grow, from 18.6 in the average household in 
>> 2021
>> to 20.2 in the first half of 2022.58 Taking these factors into account
>> suggests that fixed broadband download/upload needs could easily 
>> exceed
>> 100/20 Mbps.
>> 
>> ...
>> 
>> Service Quality. We recognize that other factors, besides the speed of 
>> a
>> broadband connection, can affect consumers’ ability to use the 
>> services
>> effectively. Chief among these factors is latency, which is the 
>> measure
>> of the time it takes a packet of data to travel from one point in the
>> network to another, and which is typically measured by round-trip time
>> in milliseconds (ms). As a measurement of advanced telecommunications
>> capability, latency can be critical because it affects a consumer’s
>> ability to use real-time applications, including voice over Internet
>> Protocol, video calling, distance learningapplications, and online
>> gaming. Actual (as opposed to advertised) speed received, consistency 
>> of
>> speed, and data allowances are also important. Such factors are not
>> simply a matter of service interruptions and consumer 
>> satisfaction—they
>> have a real and significant effect on Americans’ ability to use 
>> critical
>> web-based applications, including those that facilitate telehealth,
>> telework, and virtual learning.
>> 
>> 
>> 
>> > In the beginning days of the Arpanet, circa early 1970s, ARPA made a
>> > policy decision about use of the Arpanet.  First, Arpa Program
>> > Managers, located on the East Coast of the US, were assigned computer
>> > accounts on USC-ISIA, located on the West Coast in LA.  Thus to do
>> > their work, exchanging email, editting documents, and such, they had
>> > to *use* the Arpanet to connect their terminals in Washington to the
>> > PDP-10 in California - 3000 miles away.
>> >
>> > Second, ARPA began requiring all of their contractors (researchers at
>> > Universities etc.) to interact with Arpa using email and FTP.   If
>> > your site was "on the Arpanet", you had to use the Arpanet.  If you
>> > wanted your proposal for next year's research to be funded, you had to
>> > submit your proposal using the net.
>> >
>> > This policy caused a profound attention, by everyone involved, to
>> > making the Arpanet work and be useful as a collaboration tool.
>> >
>> > JCR Licklider (aka Lick) was my advisor at MIT, and then my boss when
>> > I joined the Research Staff.   Lick had been at ARPA for a while,
>> > promoting his vision of a "Galactic Network" that resulted in the
>> > Arpanet as a first step.  At MIT, Lick still had need for lots of
>> > interactions with others.   My assignment was to build and operate the
>> > email system for Lick's group at MIT on our own PDP-10.  Lick had a
>> > terminal in his office and was online a lot.   If email didn't work, I
>> > heard about it.   If the Arpanet didn't work, BBN heard about it.
>> >
>> > This pressure was part of Arpa policy.   Sometimes it's referred to as
>> > "eating your own dog food" -- i.e., making sure your "dog" will get
>> > the same kind of nutrition you enjoy.   IMHO, that pressure policy was
>> > important, perhaps crucial, to the success of the Arpanet.
>> >
>> > In the 70s, meetings still occurred, but a lot of progress was made
>> > through the use of the Arpanet.   You can only do so much with email
>> > and file interactions.  Today, the possibilities for far richer
>> > interactions are much more prevalent.   But IMHO they are held back,
>> > possibly because no one is feeling the pressure to "make it work".
>> > Gigabit throughputs are common, but why does my video and audio still
>> > break up...?
>> >
>> > It's important to have face-to-face meetings, but perhaps if the IETF
>> > scheduled a future meeting to be online only, whatever needs to happen
>> > to make it work would happen?  Perhaps...
>> >
>> > Even a "game" might drive progress.  At Interop '92, we resurrected
>> > the old "MazeWars" game using computers scattered across the show
>> > exhibit halls.  The engineers in the control room above the floor felt
>> > the pressure to make sure the Game continued to run.  At the time, the
>> > Internet itself was too slow for enjoyable gameplay at any distance.
>> > Will the Internet 30 years later work?
>> >
>> > Or perhaps the IETF, or ISOC, or someone could take on a highly
>> > visible demo involving non-techie end users.   An online meeting of
>> > the UN General Assembly?   Or some government bodies - US Congress,
>> > British Parliament, etc.
>> >
>> > Such an event would surface the issues, both technical and policy, to
>> > the engineers, corporations, policy-makers, and others who might have
>> > the ability and interest to "make it work".
>> >
>> > Jack
>> >
>> > On 11/14/23 10:10, Sebastian Moeller wrote:
>> >
>> >> Hi Jack,
>> >>
>> >>> On Nov 14, 2023, at 13:02, Jack Haverty via Nnagain
>> >>> <nnagain@lists.bufferbloat.net> wrote:
>> >>>
>> >>> If video conferencing worked well enough, they would not have to
>> >>> all get together in one place and would instead hold IETF meetings
>> >>> online ...?
>> >>
>> >> [SM] Turns out that humans are social creatures, and some things
>> >> work better face-to-face and in the hallway (and if that is only
>> >> building trust and sympathy) than over any remote technology.
>> >>
>> >>> Did anyone measure latency?   Does anyone measure throughput of
>> >>> "useful" traffic - e.g., excluding video/audio data that didn't
>> >>> arrive in time to be actually used on the screen or speaker?
>> >>
>> >> [SM] Utility is in the eye of the beholder, no?
>> >>
>> >> Jack Haverty
>> >>
>> >> On 11/14/23 09:25, Vint Cerf via Nnagain wrote:
>> >>
>> >> if they had not been all together they would have been consuming
>> >> tons of video capacity doing video conference calls....
>> >>
>> >> :-))
>> >> v
>> >>
>> >> On Tue, Nov 14, 2023 at 10:46 AM Livingood, Jason via Nnagain
>> >> <nnagain@lists.bufferbloat.net> wrote:
>> >> On the subject of how much bandwidth does one household need, here's
>> >> a fun stat for you.
>> >>
>> >> At the IETF’s 118th meeting last week (Nov 4 – 10, 2023), there
>> >> were over 1,000 engineers in attendance. At peak there were 870
>> >> devices connected to the WiFi network. Peak bandwidth usage:
>> >>
>> >> • Downstream peak ~750 Mbps
>> >> • Upstream ~250 Mbps
>> >>
>> >> From my pre-meeting Twitter poll
>> >> (https://twitter.com/jlivingood/status/1720060429311901873):
>> >>
>> >> <image001.png>
>> >>
>> >> _______________________________________________
>> >> Nnagain mailing list
>> >> Nnagain@lists.bufferbloat.net
>> >> https://lists.bufferbloat.net/listinfo/nnagain
>> >>
>> >> --
>> >> Please send any postal/overnight deliveries to:
>> >> Vint Cerf
>> >> Google, LLC
>> >> 1900 Reston Metro Plaza, 16th Floor
>> >> Reston, VA 20190
>> >> +1 (571) 213 1346
>> >>
>> >> until further notice
>> >>
>> >> _______________________________________________
>> >> Nnagain mailing list
>> >>
>> >> Nnagain@lists.bufferbloat.net
>> >> https://lists.bufferbloat.net/listinfo/nnagain
>> >>
>> >> _______________________________________________
>> >> Nnagain mailing list
>> >> Nnagain@lists.bufferbloat.net
>> >> https://lists.bufferbloat.net/listinfo/nnagain
>> > _______________________________________________
>> > Nnagain mailing list
>> > Nnagain@lists.bufferbloat.net
>> > https://lists.bufferbloat.net/listinfo/nnagain
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain

[-- Attachment #2: WiFiLowLatencyTech.png --]
[-- Type: image/png, Size: 159024 bytes --]

Re: [NNagain] Virtual mtgs and conferences vs. in-person ones (was) Re: FCC NOI due dec 1 on broadband speed standards

[Jack Haverty]

[-- Attachment #1: Type: text/plain, Size: 14698 bytes --]

I agree that virtual meetings today are vastly inferior to physical 
presence, but I wasn't suggesting that all meetings be made virtual.  
Rather I was suggesting that orchestrating some kind of high profile 
"virtual meeting", including not only engineers but also government 
leaders, policy makers, and other "normal" (non-technical) people, might 
be a good way to surface the issues and cross-educate the various 
communities.  Politicians don't understand "bufferbloat" or acronyms.   
Techies don't understand why politicians don't understand.

But physical meetings also have limitations.   Many people do not have 
the time or money available to travel to a meeting.  Encounters such as 
hallway conversations are often very fruitful, but they only occur if 
the people involved happen to be in the same corridor at the same time 
and have time to stop and chat.   Serendipity seems like an imperfect 
strategy to make progress.

Internet technology today is, IMHO, a rudimentary first step toward what 
could be done.  Electronic mail was a start, back in the 1970s.  It 
didn't replace physical meetings, but it enabled a lot more progress to 
happen quickly.  Technology has advanced exponentially since then.  
Perhaps there's now ways to use it better.

Perhaps a conferencing scheme (software, protocols, algorithms) could 
facilitate virtual hallway encounters by noticing that several people 
have elsewhere discussed some topic, conclude that they have a common 
interest, and suggest that they get together spontaneously online for a 
hallway discussion?  Or perhaps you heard a hallway discussion and want 
to follow up, but can't remember exactly who you were talking with.   
Computers are good at keeping records and searching them for patterns 
and overlaps even now.   As AI further develops, they'll hopefully get 
better.

In the early days of the Internet, there were research efforts exploring 
how to *use* computers and networks in support of human interactions.  
Some of that was technical - protocols, algorithms et al - but it also 
included social, political, and other non-technical aspects.   Lots of 
productive discussions in the early days of networking occurred in the 
hotel bar after the formal sessions -- but only if you were staying in 
that hotel.   Can technology, all technology not just the pieces that 
move data, somehow facilitate such human interactions?  That was the 
focus of the research.

I probably won't see it, but I suspect that before long it will be 
possible for human "meetings" using holographic displays, instead of 
today's flat screens.  The technology will continue to improve, not only 
in the pieces that move bits around but also in the computers and 
software that lives in our pockets, desks, cars, home appliances, and 
whatever else you can imagine.

Long ago I was indoctrinated into Licklider's vision of a "Galactic 
Network", which used the power of ubiquitous interconnected computers to 
help people do everything people do.  Today's Internet sure feels like 
the first incarnation of that vision.   Are researchers working on the next?

Even today, you can see many "talk show" TV programs where the 
participants sit around a table and hold discussions, but several of 
them are large computer screens, and the actual people are sometimes 
continents away.  Some such presentations are visibly perfect. Others 
suffer from audio and video dropouts, or unexpected and embarassing 
disconnects.   Are they using the Internet?  Maybe, I can't tell if a 
packet got bloated or a stagehand tripped over a wire.   Same result, 
from an end user's perspective.   Is it from an Internet problem?  Not 
enough resources, or flawed design?  Is anybody investigating?  Should 
the government make some rules?

Still, that first Arpa principle remains and IMHO is still very valid.  
Get the *users* involved, especially the non-technical ones.   
Encourage, or somehow force, everyone to use what they're creating, 
envision what might be possible, and make it happen.

Perhaps what we have today is simply the best that can be done.   I hope 
not.

Jack Haverty


On 11/14/23 12:55, David Bray, PhD via Nnagain wrote:
> Also a recent Nature study - audio conversations are better at 
> creative brainstorms and ideation then audio+video (over whatever 
> video platform of choice). Aside from the empirical findings, the 
> proposed reason why is video has people's brains trying to make sense 
> of a non-life sized images of talking heads presented to us in ways 
> that our historical evolutionary experiences is going "WTF?" at the 
> subconscious and unconscious levels.
>
> There's even some evidence that 2D flat videos actually have the body 
> in a continuous state of alertness for a potential threat - again 
> because our brains are trying to figure out whether these non-life 
> sized images of talking heads are a threat or not? (Stay tuned if 
> there's ever a lawsuit against an employer for forcing employees to 
> endure too many streaming video meetings).
>
>
>   Virtual communication curbs creative idea generation
>
>
> https://www.nature.com/articles/s41586-022-04643-y
>
> *In a laboratory study and a field experiment across five countries 
> (in Europe, the Middle East and South Asia), we show that 
> videoconferencing inhibits the production of creative ideas. *
>
> [But also]
>
> *By contrast, when it comes to selecting which idea to pursue, we find 
> no evidence that videoconferencing groups are less effective (and 
> preliminary evidence that they may be more effective) than in-person 
> groups. *
>
> [And finally]
> *
> *
> *Specifically, using eye-gaze and recall measures, as well as latent 
> semantic analysis, we demonstrate that videoconferencing hampers idea 
> generation because it focuses communicators on a screen, which prompts 
> a narrower cognitive focus. Our results suggest that virtual 
> interaction comes with a cognitive cost for creative idea generation.*
>
>
>
> On Tue, Nov 14, 2023 at 3:37 PM Dick Roy via Nnagain 
> <nnagain@lists.bufferbloat.net> wrote:
>
>     Stanford did a study a number of years ago on how information is
>     conveyed between humans.  How much of the information conveyed is
>     contained in the words that are spoken???    Answer ... less than
>     20%.  That alone explains why F2F is sooooooo important ...
>
>     -----Original Message-----
>     From: Nnagain [mailto:nnagain-bounces@lists.bufferbloat.net] On
>     Behalf Of David Lang via Nnagain
>     Sent: Tuesday, November 14, 2023 12:01 PM
>     To: Sebastian Moeller via Nnagain
>     Cc: David Lang
>     Subject: Re: [NNagain] FCC NOI due dec 1 on broadband speed standards
>
>     It's really hard to overhear a nearby conversation that catches
>     your interest in
>     a zoom environment compared to what happens at the 'hallway track'
>     when you are
>     in-person
>
>     If all you are interested in is the session contents, then video
>     recordings
>     (possibly supplemented by the ability to ask questions) is all you
>     need.
>
>     but good conferences offer much more than just that.
>
>     David Lang
>
>
>     On Tue, 14 Nov 2023, Sebastian Moeller via Nnagain wrote:
>
>     > Hi Jack,
>     >
>     > My argument is this is not a hard or software problem, but a
>     wetware problem, hard to shake off million years of evolution. And
>     IIRC during covid, didn't the IETF do online only meetings?
>     >
>     > I am not saying video conferencing is doomed, it came a long way
>     in the covid years and is 'here to stay', but it will only replace
>     face to face meetings for some conditions, is all I am saying....
>     >
>     > On 14 November 2023 14:27:28 GMT-05:00, Jack Haverty
>     <jack@3kitty.org> wrote:
>     >> In the beginning days of the Arpanet, circa early 1970s, ARPA
>     made a policy decision about use of the Arpanet.  First, Arpa
>     Program Managers, located on the East Coast of the US, were
>     assigned computer accounts on USC-ISIA, located on the West Coast
>     in LA. Thus to do their work, exchanging email, editting
>     documents, and such, they had to *use* the Arpanet to connect
>     their terminals in Washington to the PDP-10 in California - 3000
>     miles away.
>     >>
>     >> Second, ARPA began requiring all of their contractors
>     (researchers at Universities etc.) to interact with Arpa using
>     email and FTP. If your site was "on the Arpanet", you had to use
>     the Arpanet. If you wanted your proposal for next year's research
>     to be funded, you had to submit your proposal using the net.
>     >>
>     >> This policy caused a profound attention, by everyone involved,
>     to making the Arpanet work and be useful as a collaboration tool.
>     >>
>     >> JCR Licklider (aka Lick) was my advisor at MIT, and then my
>     boss when I joined the Research Staff.   Lick had been at ARPA for
>     a while, promoting his vision of a "Galactic Network" that
>     resulted in the Arpanet as a first step.  At MIT, Lick still had
>     need for lots of interactions with others.   My assignment was to
>     build and operate the email system for Lick's group at MIT on our
>     own PDP-10. Lick had a terminal in his office and was online a
>     lot.   If email didn't work, I heard about it.   If the Arpanet
>     didn't work, BBN heard about it.
>     >>
>     >> This pressure was part of Arpa policy.  Sometimes it's referred
>     to as "eating your own dog food" -- i.e., making sure your "dog"
>     will get the same kind of nutrition you enjoy.   IMHO, that
>     pressure policy was important, perhaps crucial, to the success of
>     the Arpanet.
>     >>
>     >> In the 70s, meetings still occurred, but a lot of progress was
>     made through the use of the Arpanet.   You can only do so much
>     with email and file interactions.  Today, the possibilities for
>     far richer interactions are much more prevalent.   But IMHO they
>     are held back, possibly because no one is feeling the pressure to
>     "make it work". Gigabit throughputs are common, but why does my
>     video and audio still break up...?
>     >>
>     >> It's important to have face-to-face meetings, but perhaps if
>     the IETF scheduled a future meeting to be online only, whatever
>     needs to happen to make it work would happen?  Perhaps...
>     >>
>     >> Even a "game" might drive progress.  At Interop '92, we
>     resurrected the old "MazeWars" game using computers scattered
>     across the show exhibit halls.  The engineers in the control room
>     above the floor felt the pressure to make sure the Game continued
>     to run.  At the time, the Internet itself was too slow for
>     enjoyable gameplay at any distance.   Will the Internet 30 years
>     later work?
>     >>
>     >> Or perhaps the IETF, or ISOC, or someone could take on a highly
>     visible demo involving non-techie end users.   An online meeting
>     of the UN General Assembly?   Or some government bodies - US
>     Congress, British Parliament, etc.
>     >>
>     >> Such an event would surface the issues, both technical and
>     policy, to the engineers, corporations, policy-makers, and others
>     who might have the ability and interest to "make it work".
>     >>
>     >> Jack
>     >>
>     >>
>     >> On 11/14/23 10:10, Sebastian Moeller wrote:
>     >>> Hi Jack,
>     >>>
>     >>>
>     >>>> On Nov 14, 2023, at 13:02, Jack Haverty via
>     Nnagain<nnagain@lists.bufferbloat.net> wrote:
>     >>>>
>     >>>> If video conferencing worked well enough, they would not have
>     to all get together in one place and would instead hold IETF
>     meetings online ...?
>     >>>     [SM] Turns out that humans are social creatures, and some
>     things work better face-to-face and in the hallway (and if that is
>     only building trust and sympathy) than over any remote technology.
>     >>>
>     >>>
>     >>>> Did anyone measure latency?   Does anyone measure throughput
>     of "useful" traffic - e.g., excluding video/audio data that didn't
>     arrive in time to be actually used on the screen or speaker?
>     >>>     [SM] Utility is in the eye of the beholder, no?
>     >>>
>     >>>
>     >>>> Jack Haverty
>     >>>>
>     >>>>
>     >>>> On 11/14/23 09:25, Vint Cerf via Nnagain wrote:
>     >>>>> if they had not been all together they would have been
>     consuming tons of video capacity doing video conference calls....
>     >>>>>
>     >>>>> :-))
>     >>>>> v
>     >>>>>
>     >>>>>
>     >>>>> On Tue, Nov 14, 2023 at 10:46 AM Livingood, Jason via
>     Nnagain<nnagain@lists.bufferbloat.net> wrote:
>     >>>>> On the subject of how much bandwidth does one household
>     need, here's a fun stat for you.
>     >>>>>
>     >>>>>   At the IETF’s 118th meeting last week (Nov 4 – 10, 2023),
>     there were over 1,000 engineers in attendance. At peak there were
>     870 devices connected to the WiFi network. Peak bandwidth usage:
>     >>>>>
>     >>>>>   • Downstream peak ~750 Mbps
>     >>>>>   • Upstream ~250 Mbps
>     >>>>>    From my pre-meeting Twitter poll
>     (https://twitter.com/jlivingood/status/1720060429311901873):
>     >>>>>
>     >>>>> <image001.png>
>     >>>>>
>     >>>>> _______________________________________________
>     >>>>> Nnagain mailing list
>     >>>>> Nnagain@lists.bufferbloat.net
>     >>>>> https://lists.bufferbloat.net/listinfo/nnagain
>     >>>>>
>     >>>>>
>     >>>>> --
>     >>>>> Please send any postal/overnight deliveries to:
>     >>>>> Vint Cerf
>     >>>>> Google, LLC
>     >>>>> 1900 Reston Metro Plaza, 16th Floor
>     >>>>> Reston, VA 20190
>     >>>>> +1 (571) 213 1346
>     >>>>>
>     >>>>>
>     >>>>> until further notice
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>> _______________________________________________
>     >>>>> Nnagain mailing list
>     >>>>>
>     >>>>> Nnagain@lists.bufferbloat.net
>     >>>>> https://lists.bufferbloat.net/listinfo/nnagain
>     >>>> _______________________________________________
>     >>>> Nnagain mailing list
>     >>>> Nnagain@lists.bufferbloat.net
>     >>>> https://lists.bufferbloat.net/listinfo/nnagain
>     >
>     >
>
>     _______________________________________________
>     Nnagain mailing list
>     Nnagain@lists.bufferbloat.net
>     https://lists.bufferbloat.net/listinfo/nnagain
>
>
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain

[-- Attachment #2: Type: text/html, Size: 25925 bytes --]

Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

[Jack Haverty]

[-- Attachment #1: Type: text/plain, Size: 2843 bytes --]

Interesting!   I noticed that participants are limited to receive-only, 
with only one able to speak at any time.  From the guide:

"The general expectation is that participants will send audio or video 
/only/ when recognized by a session chair as part of the queue."

That seems rather different from a virtual meeting in which hearty 
discussions, arguments, interruptions, whispered side-discussions, and 
such could approximate an in-person meeting.  It seems more like an 
audience watching a series of remote presentations than a forum for 
discussions and debates, hallway encounters, and such.

If that's a "remote experience as good as possible", what are the 
limiting factor(s) preventing a richer form of interactions?    Is it 
IETF policy, unwritten software, inadequate network performance, or ???

Are there any measurements taken?   Do the remote participants feel that 
they can participate as well as if they were onsite?   Does the 
experience vary depending on how remote you are from the meeting venue?  
How does the network bandwidth and delay behave during meetings?

Jack Haverty


On 11/14/23 12:52, Livingood, Jason wrote:
>
> > And IIRC during covid, didn't the IETF do online only meetings?
>
> Yes, we did! The IETF pivoted in March 2020 to fully virtual with 701 
> remote attendees. That continued for 2 years until March 2022 when we 
> started having in-person again – and since that time they have been 
> hybrid (and will continue to be so). The IETF also invested quite a 
> lot in online meeting tools 
> <https://www.ietf.org/how/meetings/technology/meetecho-guide-participant/> 
> & supporting systems to try to make the remote experience as good as 
> possible.
>
> IETF 118
>
> November 04-10, 2023, Prague, Czech Republic & Online
>
> 1067 onsite attendees
>
> 739 remote attendees
>
> IETF 117
>
> July 22-28, 2023, San Francisco, California & Online
>
> 890 onsite attendees
>
> 544 remote attendees
>
> IETF 116
>
> March 25-31, 2023, Yokohama, Japan & Online
>
> 993 onsite attendees
>
> 594 remote attendees
>
> IETF 115
>
> November 5-11, 2022, London, UK & Online
>
> 849 onsite attendees
>
> 667 remote attendees
>
> IETF 114
>
> July 23-29, 2022, Philadelphia, Pennsylvania & Online
>
> 618 onsite attendees
>
> 675 remote attendees
>
> IETF 113
>
> March 19-25, 2022, Vienna, Austria & Online
>
> 314 onsite attendees
>
> 976 remote attendees
>
> IETF 112
>
> November 08-12, 2021, Online
>
> 1177 remote attendees
>
> IETF 111
>
> July 26-30, 2021, Online
>
> 1206 remote attendees
>
> IETF 110
>
> March 8-12, 2021, Online
>
> 1177 remote attendees
>
> IETF 109
>
> November 16-20, 2020, Online
>
> 1061 remote attendees
>
> IETF 108
>
> July 27-31, 2020, Online
>
> 1102 remote attendees
>
> IETF 107
>
> March 23-27, 2020, Virtual
>
> 701 remote attendees
>
> //end//
>

[-- Attachment #2: Type: text/html, Size: 9686 bytes --]

Re: [NNagain] FCC NOI due dec 1 on broadband speed standards

[Robert McMahon]

[-- Attachment #1: Type: text/plain, Size: 3521 bytes --]

The hackathon element requires in person with equipment. So there's that too.

⁣Bob

On Nov 15, 2023, 4:27 PM, at 4:27 PM, Jack Haverty via Nnagain <nnagain@lists.bufferbloat.net> wrote:
>Interesting!   I noticed that participants are limited to receive-only,
>
>with only one able to speak at any time.  From the guide:
>
>"The general expectation is that participants will send audio or video
>/only/ when recognized by a session chair as part of the queue."
>
>That seems rather different from a virtual meeting in which hearty
>discussions, arguments, interruptions, whispered side-discussions, and
>such could approximate an in-person meeting.  It seems more like an
>audience watching a series of remote presentations than a forum for
>discussions and debates, hallway encounters, and such.
>
>If that's a "remote experience as good as possible", what are the
>limiting factor(s) preventing a richer form of interactions?    Is it
>IETF policy, unwritten software, inadequate network performance, or ???
>
>Are there any measurements taken?   Do the remote participants feel
>that
>they can participate as well as if they were onsite?   Does the
>experience vary depending on how remote you are from the meeting
>venue? 
>How does the network bandwidth and delay behave during meetings?
>
>Jack Haverty
>
>
>On 11/14/23 12:52, Livingood, Jason wrote:
>>
>> > And IIRC during covid, didn't the IETF do online only meetings?
>>
>> Yes, we did! The IETF pivoted in March 2020 to fully virtual with 701
>
>> remote attendees. That continued for 2 years until March 2022 when we
>
>> started having in-person again – and since that time they have been
>> hybrid (and will continue to be so). The IETF also invested quite a
>> lot in online meeting tools
>>
><https://www.ietf.org/how/meetings/technology/meetecho-guide-participant/>
>
>> & supporting systems to try to make the remote experience as good as
>> possible.
>>
>> IETF 118
>>
>> November 04-10, 2023, Prague, Czech Republic & Online
>>
>> 1067 onsite attendees
>>
>> 739 remote attendees
>>
>> IETF 117
>>
>> July 22-28, 2023, San Francisco, California & Online
>>
>> 890 onsite attendees
>>
>> 544 remote attendees
>>
>> IETF 116
>>
>> March 25-31, 2023, Yokohama, Japan & Online
>>
>> 993 onsite attendees
>>
>> 594 remote attendees
>>
>> IETF 115
>>
>> November 5-11, 2022, London, UK & Online
>>
>> 849 onsite attendees
>>
>> 667 remote attendees
>>
>> IETF 114
>>
>> July 23-29, 2022, Philadelphia, Pennsylvania & Online
>>
>> 618 onsite attendees
>>
>> 675 remote attendees
>>
>> IETF 113
>>
>> March 19-25, 2022, Vienna, Austria & Online
>>
>> 314 onsite attendees
>>
>> 976 remote attendees
>>
>> IETF 112
>>
>> November 08-12, 2021, Online
>>
>> 1177 remote attendees
>>
>> IETF 111
>>
>> July 26-30, 2021, Online
>>
>> 1206 remote attendees
>>
>> IETF 110
>>
>> March 8-12, 2021, Online
>>
>> 1177 remote attendees
>>
>> IETF 109
>>
>> November 16-20, 2020, Online
>>
>> 1061 remote attendees
>>
>> IETF 108
>>
>> July 27-31, 2020, Online
>>
>> 1102 remote attendees
>>
>> IETF 107
>>
>> March 23-27, 2020, Virtual
>>
>> 701 remote attendees
>>
>> //end//
>>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Nnagain mailing list
>Nnagain@lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/nnagain

[-- Attachment #2: Type: text/html, Size: 9725 bytes --]

[NNagain] Metrics for Network Managers (was FCC NOI due dec 1 on broadband speed standards)

[Jack Haverty]

[-- Attachment #1: Type: text/plain, Size: 17235 bytes --]

During the 90s, I was part of a small team responsible for operating a 
corporate small-i internet.  We used cisco equipment, in offices in 100 
or so countries, all interconnected with circuits from various "phone 
companies".  No fiber or wifi around yet.  Our internet was not 
connected to The Internet, but used all the same equipment and software.

To figure out how to respond to user complaints (e.g., "The network is 
really slow today!"), we discovered that we needed good instrumentation 
not only in the various routers but also in the computers in the user 
environments.   TCP, implemented in the user computers, did a good job 
at hiding problems.  For example, TCPs could get into a semi-stable 
state where every datagram was getting transmitted twice with the second 
copy being discarded at the destination.  That caused "network 
throughput" (datagrams/second) to go way up, but user performance to go 
way down.

To get the data, we used SNMP and simple scripts to probe the various 
devices from our NOC, stuff all the data into a database, and use the 
available data analysis tools to figure out what was happening.  At the 
time, SNMP "MIB"s were defined for both routers and computers.   So we 
could collect data from the TCPs involved in a problem, as well as data 
from router operations.  When routers reported N datagrams/time, the 
associated TCPs might report N/2 retransmissions from the sender, and 
N/2 discards from the receiver.

With today's ability to synchronize clocks across the network, it should 
now also be possible to report data about latency. Interactive 
operations - (A/V conferencing, gaming, telepresence, etc.) probably 
have lots of metrics that could be useful much as we found TCP's to be.

I'm way out of touch with network operations now.  Do current network 
managers look at metrics from the enduser computers' perspective?   Can 
latency be measured between two user devices involved in a problem report?

Jack



On 11/14/23 13:45, rjmcmahon via Nnagain wrote:
> I think the missing metrics & test vectors are around latency more 
> than bandwidth.
>
> I've attached a WiFi low latency table. Feel free to comment.
>
> Good metrics could allow for a comprehensive analysis, at least from a 
> WiFi perspective.
>
> Latency under load is a good start, but likely not enough.
>
> Bob
>
> PS. Agreed, the digital transition with storage has many engineers who 
> have contributed over decades. I'm very grateful to all of them.
>
>> I am glad you are reaching out, but it may be difficult for us to do a
>> joint filing.
>>
>> In particular I question the seeming assumption that more wifi devices
>> will drive demand for more bandwidth,
>> and extrapolating from 18 devices forward may also well be a trend
>> that will reverse completely in favor of more bluetooth and thread
>> implementations from phone to device.
>>
>> Of those 20 wifi devices today are probably
>>
>> 1 or more laptops
>> 1 or more tablets
>> 1 or more phones
>> 1 or more tvs
>>
>> and of those usually only one will be active per person, while they
>> are in the home, and even then....as one semi-hard number, even at
>> peak hours (with the libreqos data I have), only 1/6th of households
>> are watching video, and very, very few, more than one stream at the
>> same time.
>>
>> The steady upload bandwidth pumpers are primarily video surveillance
>> devices (which as a personal preference I would prefer remain in the
>> home unless otherwise activated). I do not presently know much about
>> the frame rates or real bandwidth requirements of popular devices like
>> ring, etc.  Similarly I am biased towards "Babycams" sending video
>> from up to downstairs only and not into the cloud. I know I am bucking
>> the trend on this, but it will make me skeptical of much "data" that
>> exists today on it.
>>
>> Then you have loads of extremely low bandwidth devices - alexa and
>> other automation is measured in bits/ms, light switches, a couple bits
>> a day, audio streaming 128kbit/s (when you use it). Automatic updates
>> to phones and tablets, etc, take place entirely asynchronously
>> nowadays and do not need much bandwidth. A small business just needs
>> to
>> *reliably* clear credit card transactions every few minutes.
>>
>> Perhaps the biggest steady-state bandwidth suck is home gaming
>> updates, but while a big market, if you haven't noticed birthrates are
>> down, and immigration being canceled.
>>
>> Thus I feel that the opposite number of 70-80% two people or less per
>> household  that you are not optimizing for, dominates the curves.
>>
>> Looking at the actual useage disparity (delta) between fiber'd cities
>> and rural, uptake of passive video streaming services vs spotify,
>> would give me a more pessimistic projection than most. Regrettably I
>> lack the time and as few fund accurate scenarios, I would merely be
>> willing to write down my estimate and find some sort of online
>> "futures" market to place puts on.
>>
>> Lastly, a goodly percentage of the people I know just need food,
>> shelter, a job and a phone, and with broadband costs skyrocketing,
>> aside from the gaming market and business, that is all they can
>> afford, even with ACP.  And all that they need. Nobody has a landline
>> anymore, and if it weren't for "Tv", few would want broadband at even
>> 25/10.
>>
>>
>> On Tue, Nov 14, 2023 at 2:40 PM rjmcmahon via Nnagain
>> <nnagain@lists.bufferbloat.net> wrote:
>>>
>>> Thanks for sharing this. I agree this works for researchers.
>>>
>>> I think we're at a different state and economic returns matter too.
>>>
>>> I sent the following to our engineers in hopes we can all better
>>> understand what we're all trying to accomplish.
>>>
>>> Hi All,
>>>
>>> The attached Notice of Inquiry by the FCC shows how much our work
>>> matters to most everyone in our country (and, by inference, worldwide.)
>>> Broadband networks are no longer entertainment or social networks but
>>> they are critical to all regardless of gender, age, race, ethnic group,
>>> etc. People's health, learning, and ability to earn for their families
>>> all depend on us providing world class engineering to our customers who
>>> in turn provide these networks for each and all of us, our friends &
>>> families, our neighbors, and most everyone else.
>>>
>>> Early in my career, I worked at Cisco and had the privilege to work on
>>> some of the first BGP routers that enabled the commercial build out of
>>> the internet, and I'm very thankful we did that way ahead of the 2019
>>> pandemic. There was no "pandemic use case" that drove us - we just
>>> wanted to build the best products that engineers could build. A
>>> worldwide pandemic w/o the internet could have been disastrous - so 
>>> that
>>> work by many in the mid 1990s seems to have paid off well.
>>>
>>> I hope you each realize, today, what you've accomplished since then and
>>> continue to be a part of. It's truly significant. It's been a high 
>>> honor
>>> to work with so many of you over the last 14+ years.
>>
>> This is beautiful, btw. I feel much the same way about linux being now
>> so used heavily in the space program,
>> and all our code, and hardware, that will propagate across the solar
>> system, and of the millions of people, that contributed to it.
>>
>>> To the FCC report:
>>>
>>> We begin this annual inquiry in the wake of the COVID-19 pandemic 
>>> during
>>> which time Americans increasingly turned to their broadband connections
>>> to conduct their lives online by using telemedicine to access
>>> healthcare, working from home, attending classes remotely, 
>>> connecting by
>>> video with out-of-town family and friends, and streaming entertainment.
>>> Our experiences with the pandemic made it clear that broadband is no
>>> longer a luxury but a necessity that will only become more important
>>> with time. Never before has the critical importance of ensuring that 
>>> all
>>> Americans have access to high-speed, affordable broadband been more
>>> evident.
>>>
>>> Also note, we have more work to do. We need to increase resiliency 
>>> as an
>>> example. Also, the thing I'm most passionate about is low latency. The
>>> FCC is now recognizing the importance of that. People are slowly
>>> learning why latency is becoming equally important to capacity when it
>>> comes to quality of service.
>>>
>>> Bob
>>>
>>> PS. The rest is TLDR but I thought I post some snippets for those
>>> interested
>>>
>>> We believe that in examining household use cases, a simple summation of
>>> required speeds for individual activities may provide a misleading
>>> picture of actual broadband needs for at least three reasons. First, we
>>> believe it is appropriate to take into account at least occasional
>>> downloads of very large files which can be bandwidth-intensive. Second,
>>> it is important to account for larger households; in 2022, 
>>> approximately
>>> 21% of all U.S. households had four or more people, and the number of
>>> families seeking out multigenerational homes to live with additional
>>> relatives rose.57 Households of all sizes must have sufficient 
>>> bandwidth
>>> to satisfy their needs. In addition, the number of connected devices 
>>> per
>>> household continues to grow, from 18.6 in the average household in 2021
>>> to 20.2 in the first half of 2022.58 Taking these factors into account
>>> suggests that fixed broadband download/upload needs could easily exceed
>>> 100/20 Mbps.
>>>
>>> ...
>>>
>>> Service Quality. We recognize that other factors, besides the speed 
>>> of a
>>> broadband connection, can affect consumers’ ability to use the services
>>> effectively. Chief among these factors is latency, which is the measure
>>> of the time it takes a packet of data to travel from one point in the
>>> network to another, and which is typically measured by round-trip time
>>> in milliseconds (ms). As a measurement of advanced telecommunications
>>> capability, latency can be critical because it affects a consumer’s
>>> ability to use real-time applications, including voice over Internet
>>> Protocol, video calling, distance learningapplications, and online
>>> gaming. Actual (as opposed to advertised) speed received, 
>>> consistency of
>>> speed, and data allowances are also important. Such factors are not
>>> simply a matter of service interruptions and consumer satisfaction—they
>>> have a real and significant effect on Americans’ ability to use 
>>> critical
>>> web-based applications, including those that facilitate telehealth,
>>> telework, and virtual learning.
>>>
>>>
>>>
>>> > In the beginning days of the Arpanet, circa early 1970s, ARPA made a
>>> > policy decision about use of the Arpanet.  First, Arpa Program
>>> > Managers, located on the East Coast of the US, were assigned computer
>>> > accounts on USC-ISIA, located on the West Coast in LA. Thus to do
>>> > their work, exchanging email, editting documents, and such, they had
>>> > to *use* the Arpanet to connect their terminals in Washington to the
>>> > PDP-10 in California - 3000 miles away.
>>> >
>>> > Second, ARPA began requiring all of their contractors (researchers at
>>> > Universities etc.) to interact with Arpa using email and FTP.   If
>>> > your site was "on the Arpanet", you had to use the Arpanet.  If you
>>> > wanted your proposal for next year's research to be funded, you 
>>> had to
>>> > submit your proposal using the net.
>>> >
>>> > This policy caused a profound attention, by everyone involved, to
>>> > making the Arpanet work and be useful as a collaboration tool.
>>> >
>>> > JCR Licklider (aka Lick) was my advisor at MIT, and then my boss when
>>> > I joined the Research Staff.   Lick had been at ARPA for a while,
>>> > promoting his vision of a "Galactic Network" that resulted in the
>>> > Arpanet as a first step.  At MIT, Lick still had need for lots of
>>> > interactions with others.   My assignment was to build and operate 
>>> the
>>> > email system for Lick's group at MIT on our own PDP-10. Lick had a
>>> > terminal in his office and was online a lot.   If email didn't 
>>> work, I
>>> > heard about it.   If the Arpanet didn't work, BBN heard about it.
>>> >
>>> > This pressure was part of Arpa policy.   Sometimes it's referred 
>>> to as
>>> > "eating your own dog food" -- i.e., making sure your "dog" will get
>>> > the same kind of nutrition you enjoy.   IMHO, that pressure policy 
>>> was
>>> > important, perhaps crucial, to the success of the Arpanet.
>>> >
>>> > In the 70s, meetings still occurred, but a lot of progress was made
>>> > through the use of the Arpanet.   You can only do so much with email
>>> > and file interactions.  Today, the possibilities for far richer
>>> > interactions are much more prevalent.   But IMHO they are held back,
>>> > possibly because no one is feeling the pressure to "make it work".
>>> > Gigabit throughputs are common, but why does my video and audio still
>>> > break up...?
>>> >
>>> > It's important to have face-to-face meetings, but perhaps if the IETF
>>> > scheduled a future meeting to be online only, whatever needs to 
>>> happen
>>> > to make it work would happen?  Perhaps...
>>> >
>>> > Even a "game" might drive progress.  At Interop '92, we resurrected
>>> > the old "MazeWars" game using computers scattered across the show
>>> > exhibit halls.  The engineers in the control room above the floor 
>>> felt
>>> > the pressure to make sure the Game continued to run.  At the time, 
>>> the
>>> > Internet itself was too slow for enjoyable gameplay at any distance.
>>> > Will the Internet 30 years later work?
>>> >
>>> > Or perhaps the IETF, or ISOC, or someone could take on a highly
>>> > visible demo involving non-techie end users.   An online meeting of
>>> > the UN General Assembly?   Or some government bodies - US Congress,
>>> > British Parliament, etc.
>>> >
>>> > Such an event would surface the issues, both technical and policy, to
>>> > the engineers, corporations, policy-makers, and others who might have
>>> > the ability and interest to "make it work".
>>> >
>>> > Jack
>>> >
>>> > On 11/14/23 10:10, Sebastian Moeller wrote:
>>> >
>>> >> Hi Jack,
>>> >>
>>> >>> On Nov 14, 2023, at 13:02, Jack Haverty via Nnagain
>>> >>> <nnagain@lists.bufferbloat.net> wrote:
>>> >>>
>>> >>> If video conferencing worked well enough, they would not have to
>>> >>> all get together in one place and would instead hold IETF meetings
>>> >>> online ...?
>>> >>
>>> >> [SM] Turns out that humans are social creatures, and some things
>>> >> work better face-to-face and in the hallway (and if that is only
>>> >> building trust and sympathy) than over any remote technology.
>>> >>
>>> >>> Did anyone measure latency?   Does anyone measure throughput of
>>> >>> "useful" traffic - e.g., excluding video/audio data that didn't
>>> >>> arrive in time to be actually used on the screen or speaker?
>>> >>
>>> >> [SM] Utility is in the eye of the beholder, no?
>>> >>
>>> >> Jack Haverty
>>> >>
>>> >> On 11/14/23 09:25, Vint Cerf via Nnagain wrote:
>>> >>
>>> >> if they had not been all together they would have been consuming
>>> >> tons of video capacity doing video conference calls....
>>> >>
>>> >> :-))
>>> >> v
>>> >>
>>> >> On Tue, Nov 14, 2023 at 10:46 AM Livingood, Jason via Nnagain
>>> >> <nnagain@lists.bufferbloat.net> wrote:
>>> >> On the subject of how much bandwidth does one household need, here's
>>> >> a fun stat for you.
>>> >>
>>> >> At the IETF’s 118th meeting last week (Nov 4 – 10, 2023), there
>>> >> were over 1,000 engineers in attendance. At peak there were 870
>>> >> devices connected to the WiFi network. Peak bandwidth usage:
>>> >>
>>> >> • Downstream peak ~750 Mbps
>>> >> • Upstream ~250 Mbps
>>> >>
>>> >> From my pre-meeting Twitter poll
>>> >> (https://twitter.com/jlivingood/status/1720060429311901873):
>>> >>
>>> >> <image001.png>
>>> >>
>>> >> _______________________________________________
>>> >> Nnagain mailing list
>>> >> Nnagain@lists.bufferbloat.net
>>> >> https://lists.bufferbloat.net/listinfo/nnagain
>>> >>
>>> >> --
>>> >> Please send any postal/overnight deliveries to:
>>> >> Vint Cerf
>>> >> Google, LLC
>>> >> 1900 Reston Metro Plaza, 16th Floor
>>> >> Reston, VA 20190
>>> >> +1 (571) 213 1346
>>> >>
>>> >> until further notice
>>> >>
>>> >> _______________________________________________
>>> >> Nnagain mailing list
>>> >>
>>> >> Nnagain@lists.bufferbloat.net
>>> >> https://lists.bufferbloat.net/listinfo/nnagain
>>> >>
>>> >> _______________________________________________
>>> >> Nnagain mailing list
>>> >> Nnagain@lists.bufferbloat.net
>>> >> https://lists.bufferbloat.net/listinfo/nnagain
>>> > _______________________________________________
>>> > Nnagain mailing list
>>> > Nnagain@lists.bufferbloat.net
>>> > https://lists.bufferbloat.net/listinfo/nnagain
>>> _______________________________________________
>>> Nnagain mailing list
>>> Nnagain@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/nnagain
>
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain

[-- Attachment #2: Type: text/html, Size: 27365 bytes --]

Re: [NNagain] Metrics for Network Managers (was FCC NOI due dec 1 on broadband speed standards)

[rjmcmahon]

Hi Jack,

We do have challenges with network metrics and network telemetry. While 
better than the days of SNMP, there is a long way to go. Any agency, 
e.g. the FCC, trying to make quality statements about broadband networks 
really need to be steeped in these topics. Particularly before govt 
allocates financial resources to help out.

The goal with iperf 2 is to behave as a application using TCP end to end 
as that's typically the performance folks primarily care about. 
Microsecond timestamps are supported at the app level. It does require 
clock sync for one way delays and the GPS atomic clock is pretty good. 
But Richard Roy will remind us that there really is no such thing as 
clock sync per general relativity. The kernel does provide TCP stack 
stats in realtime too.

I don't think we've instrumented most networks well enough even today. 
The focus has mostly been on speeds & feeds and then now it's becoming 
low latency (though latency became important for high frequency traders 
about a decode ago for their latency arbitrage in trading - so those 
networks are close to the limits of nature and spacetime) and less on 
test & measurement. The few of us in T&M do our best.

I added little's law to iperf 2's output probably 5 years ago or more. 
It's still not utilized well across the industry. One can tell because 
the displacement units of bloat are bytes or packets but instead we use 
time or round trips. The bandwidth delay of a link isn't hard to figure 
out so determining the amount of excess queue memory in proper units has 
been doable for awhile now.

We're way behind on multivariate analysis too. Even basic statistical 
process controls (SPC) aren't heavily used. Machines could be carrying 
more of the load than they do.

There is a lot to do and only so much time. So-called AI and ChatGPT has 
most everyone's attention it seems.

Bob
> During the 90s, I was part of a small team responsible for operating
> a corporate small-i internet.  We used cisco equipment, in offices in
> 100 or so countries, all interconnected with circuits from various
> "phone companies".  No fiber or wifi around yet.  Our internet was not
> connected to The Internet, but used all the same equipment and
> software.
> 
> To figure out how to respond to user complaints (e.g., "The network is
> really slow today!"), we discovered that we needed good
> instrumentation not only in the various routers but also in the
> computers in the user environments.   TCP, implemented in the user
> computers, did a good job at hiding problems.  For example, TCPs could
> get into a semi-stable state where every datagram was getting
> transmitted twice with the second copy being discarded at the
> destination.  That caused "network throughput" (datagrams/second) to
> go way up, but user performance to go way down.
> 
> To get the data, we used SNMP and simple scripts to probe the various
> devices from our NOC, stuff all the data into a database, and use the
> available data analysis tools to figure out what was happening.  At
> the time, SNMP "MIB"s were defined for both routers and computers.
> So we could collect data from the TCPs involved in a problem, as well
> as data from router operations.  When routers reported N
> datagrams/time, the associated TCPs might report N/2 retransmissions
> from the sender, and N/2 discards from the receiver.
> 
> With today's ability to synchronize clocks across the network, it
> should now also be possible to report data about latency.
> Interactive operations - (A/V conferencing, gaming, telepresence,
> etc.) probably have lots of metrics that could be useful much as we
> found TCP's to be.
> 
> I'm way out of touch with network operations now.  Do current network
> managers look at metrics from the enduser computers' perspective?
> Can latency be measured between two user devices involved in a problem
> report?
> 
> Jack
> 
> On 11/14/23 13:45, rjmcmahon via Nnagain wrote:
> 
>> I think the missing metrics & test vectors are around latency more
>> than bandwidth.
>> 
>> I've attached a WiFi low latency table. Feel free to comment.
>> 
>> Good metrics could allow for a comprehensive analysis, at least from
>> a WiFi perspective.
>> 
>> Latency under load is a good start, but likely not enough.
>> 
>> Bob
>> 
>> PS. Agreed, the digital transition with storage has many engineers
>> who have contributed over decades. I'm very grateful to all of them.
>> 
>> 
>> I am glad you are reaching out, but it may be difficult for us to do
>> a
>> joint filing.
>> 
>> In particular I question the seeming assumption that more wifi
>> devices
>> will drive demand for more bandwidth,
>> and extrapolating from 18 devices forward may also well be a trend
>> that will reverse completely in favor of more bluetooth and thread
>> implementations from phone to device.
>> 
>> Of those 20 wifi devices today are probably
>> 
>> 1 or more laptops
>> 1 or more tablets
>> 1 or more phones
>> 1 or more tvs
>> 
>> and of those usually only one will be active per person, while they
>> are in the home, and even then....as one semi-hard number, even at
>> peak hours (with the libreqos data I have), only 1/6th of households
>> 
>> are watching video, and very, very few, more than one stream at the
>> same time.
>> 
>> The steady upload bandwidth pumpers are primarily video surveillance
>> 
>> devices (which as a personal preference I would prefer remain in the
>> 
>> home unless otherwise activated). I do not presently know much about
>> 
>> the frame rates or real bandwidth requirements of popular devices
>> like
>> ring, etc.  Similarly I am biased towards "Babycams" sending video
>> from up to downstairs only and not into the cloud. I know I am
>> bucking
>> the trend on this, but it will make me skeptical of much "data" that
>> 
>> exists today on it.
>> 
>> Then you have loads of extremely low bandwidth devices - alexa and
>> other automation is measured in bits/ms, light switches, a couple
>> bits
>> a day, audio streaming 128kbit/s (when you use it). Automatic
>> updates
>> to phones and tablets, etc, take place entirely asynchronously
>> nowadays and do not need much bandwidth. A small business just needs
>> 
>> to
>> *reliably* clear credit card transactions every few minutes.
>> 
>> Perhaps the biggest steady-state bandwidth suck is home gaming
>> updates, but while a big market, if you haven't noticed birthrates
>> are
>> down, and immigration being canceled.
>> 
>> Thus I feel that the opposite number of 70-80% two people or less
>> per
>> household  that you are not optimizing for, dominates the curves.
>> 
>> Looking at the actual useage disparity (delta) between fiber'd
>> cities
>> and rural, uptake of passive video streaming services vs spotify,
>> would give me a more pessimistic projection than most. Regrettably I
>> 
>> lack the time and as few fund accurate scenarios, I would merely be
>> willing to write down my estimate and find some sort of online
>> "futures" market to place puts on.
>> 
>> Lastly, a goodly percentage of the people I know just need food,
>> shelter, a job and a phone, and with broadband costs skyrocketing,
>> aside from the gaming market and business, that is all they can
>> afford, even with ACP.  And all that they need. Nobody has a
>> landline
>> anymore, and if it weren't for "Tv", few would want broadband at
>> even
>> 25/10.
>> 
>> On Tue, Nov 14, 2023 at 2:40 PM rjmcmahon via Nnagain
>> <nnagain@lists.bufferbloat.net> wrote:
>> 
>> Thanks for sharing this. I agree this works for researchers.
>> 
>> I think we're at a different state and economic returns matter too.
>> 
>> I sent the following to our engineers in hopes we can all better
>> understand what we're all trying to accomplish.
>> 
>> Hi All,
>> 
>> The attached Notice of Inquiry by the FCC shows how much our work
>> matters to most everyone in our country (and, by inference,
>> worldwide.)
>> Broadband networks are no longer entertainment or social networks
>> but
>> they are critical to all regardless of gender, age, race, ethnic
>> group,
>> etc. People's health, learning, and ability to earn for their
>> families
>> all depend on us providing world class engineering to our customers
>> who
>> in turn provide these networks for each and all of us, our friends &
>> 
>> families, our neighbors, and most everyone else.
>> 
>> Early in my career, I worked at Cisco and had the privilege to work
>> on
>> some of the first BGP routers that enabled the commercial build out
>> of
>> the internet, and I'm very thankful we did that way ahead of the
>> 2019
>> pandemic. There was no "pandemic use case" that drove us - we just
>> wanted to build the best products that engineers could build. A
>> worldwide pandemic w/o the internet could have been disastrous - so
>> that
>> work by many in the mid 1990s seems to have paid off well.
>> 
>> I hope you each realize, today, what you've accomplished since then
>> and
>> continue to be a part of. It's truly significant. It's been a high
>> honor
>> to work with so many of you over the last 14+ years.
>> 
>> This is beautiful, btw. I feel much the same way about linux being
>> now
>> so used heavily in the space program,
>> and all our code, and hardware, that will propagate across the solar
>> 
>> system, and of the millions of people, that contributed to it.
>> 
>> To the FCC report:
>> 
>> We begin this annual inquiry in the wake of the COVID-19 pandemic
>> during
>> which time Americans increasingly turned to their broadband
>> connections
>> to conduct their lives online by using telemedicine to access
>> healthcare, working from home, attending classes remotely,
>> connecting by
>> video with out-of-town family and friends, and streaming
>> entertainment.
>> Our experiences with the pandemic made it clear that broadband is no
>> 
>> longer a luxury but a necessity that will only become more important
>> 
>> with time. Never before has the critical importance of ensuring that
>> all
>> Americans have access to high-speed, affordable broadband been more
>> evident.
>> 
>> Also note, we have more work to do. We need to increase resiliency
>> as an
>> example. Also, the thing I'm most passionate about is low latency.
>> The
>> FCC is now recognizing the importance of that. People are slowly
>> learning why latency is becoming equally important to capacity when
>> it
>> comes to quality of service.
>> 
>> Bob
>> 
>> PS. The rest is TLDR but I thought I post some snippets for those
>> interested
>> 
>> We believe that in examining household use cases, a simple summation
>> of
>> required speeds for individual activities may provide a misleading
>> picture of actual broadband needs for at least three reasons. First,
>> we
>> believe it is appropriate to take into account at least occasional
>> downloads of very large files which can be bandwidth-intensive.
>> Second,
>> it is important to account for larger households; in 2022,
>> approximately
>> 21% of all U.S. households had four or more people, and the number
>> of
>> families seeking out multigenerational homes to live with additional
>> 
>> relatives rose.57 Households of all sizes must have sufficient
>> bandwidth
>> to satisfy their needs. In addition, the number of connected devices
>> per
>> household continues to grow, from 18.6 in the average household in
>> 2021
>> to 20.2 in the first half of 2022.58 Taking these factors into
>> account
>> suggests that fixed broadband download/upload needs could easily
>> exceed
>> 100/20 Mbps.
>> 
>> ...
>> 
>> Service Quality. We recognize that other factors, besides the speed
>> of a
>> broadband connection, can affect consumers’ ability to use the
>> services
>> effectively. Chief among these factors is latency, which is the
>> measure
>> of the time it takes a packet of data to travel from one point in
>> the
>> network to another, and which is typically measured by round-trip
>> time
>> in milliseconds (ms). As a measurement of advanced
>> telecommunications
>> capability, latency can be critical because it affects a
>> consumer’s
>> ability to use real-time applications, including voice over Internet
>> 
>> Protocol, video calling, distance learningapplications, and online
>> gaming. Actual (as opposed to advertised) speed received,
>> consistency of
>> speed, and data allowances are also important. Such factors are not
>> simply a matter of service interruptions and consumer
>> satisfaction—they
>> have a real and significant effect on Americans’ ability to use
>> critical
>> web-based applications, including those that facilitate telehealth,
>> telework, and virtual learning.
>> 
>>> In the beginning days of the Arpanet, circa early 1970s, ARPA made
>> a
>>> policy decision about use of the Arpanet.  First, Arpa Program
>>> Managers, located on the East Coast of the US, were assigned
>> computer
>>> accounts on USC-ISIA, located on the West Coast in LA.  Thus to do
>> 
>>> their work, exchanging email, editting documents, and such, they
>> had
>>> to *use* the Arpanet to connect their terminals in Washington to
>> the
>>> PDP-10 in California - 3000 miles away.
>>> 
>>> Second, ARPA began requiring all of their contractors (researchers
>> at
>>> Universities etc.) to interact with Arpa using email and FTP.   If
>> 
>>> your site was "on the Arpanet", you had to use the Arpanet.  If
>> you
>>> wanted your proposal for next year's research to be funded, you
>> had to
>>> submit your proposal using the net.
>>> 
>>> This policy caused a profound attention, by everyone involved, to
>>> making the Arpanet work and be useful as a collaboration tool.
>>> 
>>> JCR Licklider (aka Lick) was my advisor at MIT, and then my boss
>> when
>>> I joined the Research Staff.   Lick had been at ARPA for a while,
>>> promoting his vision of a "Galactic Network" that resulted in the
>>> Arpanet as a first step.  At MIT, Lick still had need for lots of
>>> interactions with others.   My assignment was to build and operate
>> the
>>> email system for Lick's group at MIT on our own PDP-10.  Lick had
>> a
>>> terminal in his office and was online a lot.   If email didn't
>> work, I
>>> heard about it.   If the Arpanet didn't work, BBN heard about it.
>>> 
>>> This pressure was part of Arpa policy.   Sometimes it's referred
>> to as
>>> "eating your own dog food" -- i.e., making sure your "dog" will
>> get
>>> the same kind of nutrition you enjoy.   IMHO, that pressure policy
>> was
>>> important, perhaps crucial, to the success of the Arpanet.
>>> 
>>> In the 70s, meetings still occurred, but a lot of progress was
>> made
>>> through the use of the Arpanet.   You can only do so much with
>> email
>>> and file interactions.  Today, the possibilities for far richer
>>> interactions are much more prevalent.   But IMHO they are held
>> back,
>>> possibly because no one is feeling the pressure to "make it work".
>> 
>>> Gigabit throughputs are common, but why does my video and audio
>> still
>>> break up...?
>>> 
>>> It's important to have face-to-face meetings, but perhaps if the
>> IETF
>>> scheduled a future meeting to be online only, whatever needs to
>> happen
>>> to make it work would happen?  Perhaps...
>>> 
>>> Even a "game" might drive progress.  At Interop '92, we
>> resurrected
>>> the old "MazeWars" game using computers scattered across the show
>>> exhibit halls.  The engineers in the control room above the floor
>> felt
>>> the pressure to make sure the Game continued to run.  At the time,
>> the
>>> Internet itself was too slow for enjoyable gameplay at any
>> distance.
>>> Will the Internet 30 years later work?
>>> 
>>> Or perhaps the IETF, or ISOC, or someone could take on a highly
>>> visible demo involving non-techie end users.   An online meeting
>> of
>>> the UN General Assembly?   Or some government bodies - US
>> Congress,
>>> British Parliament, etc.
>>> 
>>> Such an event would surface the issues, both technical and policy,
>> to
>>> the engineers, corporations, policy-makers, and others who might
>> have
>>> the ability and interest to "make it work".
>>> 
>>> Jack
>>> 
>>> On 11/14/23 10:10, Sebastian Moeller wrote:
>>> 
>>>> Hi Jack,
>>>> 
>>>>> On Nov 14, 2023, at 13:02, Jack Haverty via Nnagain
>>>>> <nnagain@lists.bufferbloat.net> wrote:
>>>>> 
>>>>> If video conferencing worked well enough, they would not have to
>> 
>>>>> all get together in one place and would instead hold IETF
>> meetings
>>>>> online ...?
>>>> 
>>>> [SM] Turns out that humans are social creatures, and some things
>>>> work better face-to-face and in the hallway (and if that is only
>>>> building trust and sympathy) than over any remote technology.
>>>> 
>>>>> Did anyone measure latency?   Does anyone measure throughput of
>>>>> "useful" traffic - e.g., excluding video/audio data that didn't
>>>>> arrive in time to be actually used on the screen or speaker?
>>>> 
>>>> [SM] Utility is in the eye of the beholder, no?
>>>> 
>>>> Jack Haverty
>>>> 
>>>> On 11/14/23 09:25, Vint Cerf via Nnagain wrote:
>>>> 
>>>> if they had not been all together they would have been consuming
>>>> tons of video capacity doing video conference calls....
>>>> 
>>>> :-))
>>>> v
>>>> 
>>>> On Tue, Nov 14, 2023 at 10:46 AM Livingood, Jason via Nnagain
>>>> <nnagain@lists.bufferbloat.net> wrote:
>>>> On the subject of how much bandwidth does one household need,
>> here's
>>>> a fun stat for you.
>>>> 
>>>> At the IETF’s 118th meeting last week (Nov 4 – 10, 2023),
>> there
>>>> were over 1,000 engineers in attendance. At peak there were 870
>>>> devices connected to the WiFi network. Peak bandwidth usage:
>>>> 
>>>> • Downstream peak ~750 Mbps
>>>> • Upstream ~250 Mbps
>>>> 
>>>> From my pre-meeting Twitter poll
>>>> (https://twitter.com/jlivingood/status/1720060429311901873):
>>>> 
>>>> <image001.png>
>>>> 
>>>> _______________________________________________
>>>> Nnagain mailing list
>>>> Nnagain@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>> 
>>>> --
>>>> Please send any postal/overnight deliveries to:
>>>> Vint Cerf
>>>> Google, LLC
>>>> 1900 Reston Metro Plaza, 16th Floor
>>>> Reston, VA 20190
>>>> +1 (571) 213 1346
>>>> 
>>>> until further notice
>>>> 
>>>> _______________________________________________
>>>> Nnagain mailing list
>>>> 
>>>> Nnagain@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>>> 
>>>> _______________________________________________
>>>> Nnagain mailing list
>>>> Nnagain@lists.bufferbloat.net
>>>> https://lists.bufferbloat.net/listinfo/nnagain
>>> _______________________________________________
>>> Nnagain mailing list
>>> Nnagain@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/nnagain
>> _______________________________________________
>> Nnagain mailing list
>> Nnagain@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/nnagain
> 
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain
> _______________________________________________
> Nnagain mailing list
> Nnagain@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/nnagain