Re: Outside plant - prewire customer demarc preference

[Josh Luthman]

Keep in mind new construction versus having to get around drywall.

2" is beyond excessive.  We use 1.25" duct for our 288ct *PLUS* up to 6
flat drop cables.

On Thu, Nov 30, 2023 at 7:45 PM Brandon Martin 
wrote:

> On 11/28/23 10:42, Mike Hammett wrote:
> > Why not just use SCH40 PVC sticks? Everywhere stocks that in copious
> levels.
>
> Ever tried to snake one of those through a wall?
>
> They're great for just pushing through a wall penetration to something
> directly adjacent on the inside, though.  At that point you might as
> well for for 2", honestly.
>
> --
> Brandon Martin
>

A "Road Less Traveled" with AWS's Les Williams + More

[Nanog News]

*From an African Refugee to an American Techie*
*A "Road Less Traveled" with AWS's Les Williams *

Maya Angelou once said, "I've learned that people will forget what you
said, people will forget what you did, but people will never forget how you
made them feel."

Les Williams, technical business development manager for Amazon Web
Services (AWS), is an unforgettable man.


*READ MORE *


*
*
*VIDEO | Highlight Reel of NANOG 89*

Watch the recap video of NANOG 89 San Diego. Experience what makes our
community special + what it is like to attend a conference.

*WATCH NOW* 

Reminder: Call for Presentations for NANOG 90
Please Note - Deadline Has Been Changed to 28 Dec*

*Specific talk topics include:*

+ Network Automation - practical uses, how to get started
+ Network Future - forecast for changes in technology, design, applications
+ More

*LEARN MORE * 

*OARC 42 Workshop will Take Place in Charlotte Before NANOG 90*

DNS-OARC is a non-profit, membership organization that seeks to improve the
security, stability, and understanding of the Internet's DNS
infrastructure. Part of these aims are achieved through workshops.

*LEARN MORE * 

Re: sigs wanted for a response to the fcc's NOI for faster broadband speeds

[Tom Mitchell]

Not sure we need the FCC telling us how to build products or run networks.
Seat belts are life-or-death, but bufferbloat is rarely fatal ;-)  Let it
be a point of differentiation.

-- Tom


On Thu, Nov 30, 2023 at 4:56 PM Dave Taht  wrote:

> Over here:
>
>
> https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4vH4/edit
>
> Us bufferbloat folk have been putting together a response to the FCC's
> NOI (notice of inquiry) asking for feedback as to increasing the
> broadband speeds beyond 100/20 Mbit.
>
> "Calls for further bandwidth increases are analogous to calling for
> cars to have top speeds of 100, 200, or 500 miles per hour. Without
> calling also for better airbags, bumpers, brakes, or steering wheels,
> (or roads designed to minimize travel delay), these initiatives will
> fail (and are failing) to meet the needs of present and future users
> of the internet."
>
> Comments (and cites) welcomed also! The text is still somewhat in flux...
>
>
> --
> :( My old R&D campus is up for sale: https://tinyurl.com/yurtlab
> Dave Täht CSO, LibreQos
>

Re: sigs wanted for a response to the fcc's NOI for faster broadband speeds

[Shane Ronan]

If you want money from the government to subsidize your network, you'll
follow their rules...

On Fri, Dec 1, 2023 at 12:39 PM Tom Mitchell 
wrote:

> Not sure we need the FCC telling us how to build products or run
> networks.  Seat belts are life-or-death, but bufferbloat is rarely fatal
> ;-)  Let it be a point of differentiation.
>
> -- Tom
>
>
> On Thu, Nov 30, 2023 at 4:56 PM Dave Taht  wrote:
>
>> Over here:
>>
>>
>> https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4vH4/edit
>>
>> Us bufferbloat folk have been putting together a response to the FCC's
>> NOI (notice of inquiry) asking for feedback as to increasing the
>> broadband speeds beyond 100/20 Mbit.
>>
>> "Calls for further bandwidth increases are analogous to calling for
>> cars to have top speeds of 100, 200, or 500 miles per hour. Without
>> calling also for better airbags, bumpers, brakes, or steering wheels,
>> (or roads designed to minimize travel delay), these initiatives will
>> fail (and are failing) to meet the needs of present and future users
>> of the internet."
>>
>> Comments (and cites) welcomed also! The text is still somewhat in flux...
>>
>>
>> --
>> :( My old R&D campus is up for sale: https://tinyurl.com/yurtlab
>> Dave Täht CSO, LibreQos
>>
>

Weekly Global IPv4 Routing Table Report

[Routing Table Analysis Role Account]

This is an automated weekly mailing describing the state of the Global
IPv4 Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, SANOG, PacNOG, SAFNOG
UKNOF, TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net.

For historical data, please see https://thyme.apnic.net.

If you have any comments please contact Philip Smith .

IPv4 Routing Table Report   04:00 +10GMT Sat 02 Dec, 2023

  BGP Table (Global) as seen in Japan.

Report Website: https://thyme.apnic.net
Detailed Analysis:  https://thyme.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  935768
Prefixes after maximum aggregation (per Origin AS):  356557
Deaggregation factor:  2.62
Unique aggregates announced (without unneeded subnets):  455208
Total ASes present in the Internet Routing Table: 75073
Prefixes per ASN: 12.46
Origin-only ASes present in the Internet Routing Table:   64404
Origin ASes announcing only one prefix:   26492
Transit ASes present in the Internet Routing Table:   10669
Transit-only ASes present in the Internet Routing Table:483
Average AS path length visible in the Internet Routing Table:   4.2
Max AS path length visible:  55
Max AS path prepend of ASN (265020)  50
Prefixes from unregistered ASNs in the Routing Table:  1061
Number of instances of unregistered ASNs:  1063
Number of 32-bit ASNs allocated by the RIRs:  43144
Number of 32-bit ASNs visible in the Routing Table:   35456
Prefixes from 32-bit ASNs in the Routing Table:  178175
Number of bogon 32-bit ASNs visible in the Routing Table:31
Special use prefixes present in the Routing Table:1
Prefixes being announced from unallocated address space:546
Number of addresses announced to Internet:   3048735744
Equivalent to 181 /8s, 184 /16s and 4 /24s
Percentage of available address space announced:   82.3
Percentage of allocated address space announced:   82.3
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.6
Total number of prefixes smaller than registry allocations:  310346

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   249452
Total APNIC prefixes after maximum aggregation:   71994
APNIC Deaggregation factor:3.46
Prefixes being announced from the APNIC address blocks:  242709
Unique aggregates announced from the APNIC address blocks:99551
APNIC Region origin ASes present in the Internet Routing Table:   13806
APNIC Prefixes per ASN:   17.58
APNIC Region origin ASes announcing only one prefix:   4163
APNIC Region transit ASes present in the Internet Routing Table:   1851
Average APNIC Region AS path length visible:4.4
Max APNIC Region AS path length visible: 32
Number of APNIC region 32-bit ASNs visible in the Routing Table:   9140
Number of APNIC addresses announced to Internet:  771358336
Equivalent to 45 /8s, 249 /16s and 254 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-153913
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:273323
Total ARIN prefixes after maximum aggregation:   124284
ARIN Deaggregation factor: 2.20
Prefixes being announced from the ARIN address blocks:   278074
Unique aggregates announced from the ARIN address blocks:132552
ARIN Region origin ASes present in the Internet Routing Table:19077
ARIN Prefixes per ASN:

Re: sigs wanted for a response to the fcc's NOI for faster broadband speeds

[Dave Taht]

On Fri, Dec 1, 2023 at 12:46 PM Shane Ronan  wrote:
>
> If you want money from the government to subsidize your network, you'll 
> follow their rules...

It is the misguided focus on too many too simple things from the
regulator and Congress, without even understanding what a packet is,
and enormous subsidies for things that don't matter, and great
mis-understanding of the things that do, that bothers me the most.

Anyway, for 14 years, I have been trying to get bufferbloat fixed,
universally, and great progress is being made. I felt that with one
political push like this, it might begin to turn the tide. We are
accepting signatures on the FCC filing until 2PM EST today.

https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4vH4/edit

> On Fri, Dec 1, 2023 at 12:39 PM Tom Mitchell  wrote:
>>
>> Not sure we need the FCC telling us how to build products or run networks.  
>> Seat belts are life-or-death, but bufferbloat is rarely fatal ;-)  Let it be 
>> a point of differentiation.
>>
>> -- Tom
>>
>>
>> On Thu, Nov 30, 2023 at 4:56 PM Dave Taht  wrote:
>>>
>>> Over here:
>>>
>>> https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4vH4/edit
>>>
>>> Us bufferbloat folk have been putting together a response to the FCC's
>>> NOI (notice of inquiry) asking for feedback as to increasing the
>>> broadband speeds beyond 100/20 Mbit.
>>>
>>> "Calls for further bandwidth increases are analogous to calling for
>>> cars to have top speeds of 100, 200, or 500 miles per hour. Without
>>> calling also for better airbags, bumpers, brakes, or steering wheels,
>>> (or roads designed to minimize travel delay), these initiatives will
>>> fail (and are failing) to meet the needs of present and future users
>>> of the internet."
>>>
>>> Comments (and cites) welcomed also! The text is still somewhat in flux...
>>>
>>>
>>> --
>>> :( 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

Re: sigs wanted for a response to the fcc's NOI for faster broadband speeds

[Mike Hammett]

The FCC is currently posturing to feel relevant. While they're in one of these 
modes, you're not going to stop them, but you might be able to redirect them on 
a better path. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Tom Mitchell"  
To: "Dave Taht"  
Cc: "NANOG" , "NZNOG" , 
""  
Sent: Friday, December 1, 2023 11:38:10 AM 
Subject: Re: sigs wanted for a response to the fcc's NOI for faster broadband 
speeds 



Not sure we need the FCC telling us how to build products or run networks. Seat 
belts are life-or-death, but bufferbloat is rarely fatal ;-) Let it be a point 
of differentiation. 




-- Tom 



On Thu, Nov 30, 2023 at 4:56 PM Dave Taht < dave.t...@gmail.com > wrote: 


Over here: 

https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4vH4/edit
 

Us bufferbloat folk have been putting together a response to the FCC's 
NOI (notice of inquiry) asking for feedback as to increasing the 
broadband speeds beyond 100/20 Mbit. 

"Calls for further bandwidth increases are analogous to calling for 
cars to have top speeds of 100, 200, or 500 miles per hour. Without 
calling also for better airbags, bumpers, brakes, or steering wheels, 
(or roads designed to minimize travel delay), these initiatives will 
fail (and are failing) to meet the needs of present and future users 
of the internet." 

Comments (and cites) welcomed also! The text is still somewhat in flux... 


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

Re: sigs wanted for a response to the fcc's NOI for faster broadband speeds

[Mel Beckman]

bufferbloat is rarely fatal

LOL! I know one person taht may disagree with that :)

 -mel

On Dec 1, 2023, at 9:41 AM, Tom Mitchell  wrote:


Not sure we need the FCC telling us how to build products or run networks.  
Seat belts are life-or-death, but bufferbloat is rarely fatal ;-)  Let it be a 
point of differentiation.

-- Tom


On Thu, Nov 30, 2023 at 4:56 PM Dave Taht 
mailto:dave.t...@gmail.com>> wrote:
Over here:

https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4vH4/edit

Us bufferbloat folk have been putting together a response to the FCC's
NOI (notice of inquiry) asking for feedback as to increasing the
broadband speeds beyond 100/20 Mbit.

"Calls for further bandwidth increases are analogous to calling for
cars to have top speeds of 100, 200, or 500 miles per hour. Without
calling also for better airbags, bumpers, brakes, or steering wheels,
(or roads designed to minimize travel delay), these initiatives will
fail (and are failing) to meet the needs of present and future users
of the internet."

Comments (and cites) welcomed also! The text is still somewhat in flux...


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

Re: sigs wanted for a response to the fcc's NOI for faster broadband speeds

[michael brooks - ESC]

As one beholden to USAC/FCC I have to agree with Shane...




michael brooks
Sr. Network Engineer
Adams 12 Five Star Schools
michael.bro...@adams12.org

"flying is learning how to throw yourself at the ground and miss"



On Fri, Dec 1, 2023 at 10:39 AM Tom Mitchell 
wrote:

> Not sure we need the FCC telling us how to build products or run
> networks.  Seat belts are life-or-death, but bufferbloat is rarely fatal
> ;-)  Let it be a point of differentiation.
>
> -- Tom
>
>
> On Thu, Nov 30, 2023 at 4:56 PM Dave Taht  wrote:
>
>> Over here:
>>
>>
>> https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4vH4/edit
>> 
>>
>> Us bufferbloat folk have been putting together a response to the FCC's
>> NOI (notice of inquiry) asking for feedback as to increasing the
>> broadband speeds beyond 100/20 Mbit.
>>
>> "Calls for further bandwidth increases are analogous to calling for
>> cars to have top speeds of 100, 200, or 500 miles per hour. Without
>> calling also for better airbags, bumpers, brakes, or steering wheels,
>> (or roads designed to minimize travel delay), these initiatives will
>> fail (and are failing) to meet the needs of present and future users
>> of the internet."
>>
>> Comments (and cites) welcomed also! The text is still somewhat in flux...
>>
>>
>> --
>> :( My old R&D campus is up for sale: https://tinyurl.com/yurtlab
>> 
>> Dave Täht CSO, LibreQos
>>
>

-- 
This is a staff email account managed by Adams 12 Five Star Schools.  This 
email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the sender.

Re: [nznog] Re: sigs wanted for a response to the fcc's NOI for faster broadband speeds

[Shane Ronan]

Is that really an appropriate response for NANOG?

On Fri, Dec 1, 2023 at 1:41 PM Geoffrey Jackson <
geoffrey.jack...@protonmail.com> wrote:

> Pussy.
>
> -Original Message-
> From: Dave Taht 
> Sent: 2 December 2023 7:11 AM
> To: Shane Ronan 
> Cc: Tom Mitchell ; NANOG ;
> NZNOG ; aus...@lists.ausnog.net
> Subject: [nznog] Re: sigs wanted for a response to the fcc's NOI for
> faster broadband speeds
>
> On Fri, Dec 1, 2023 at 12:46 PM Shane Ronan 
> wrote:
> >
> > If you want money from the government to subsidize your network, you'll
> follow their rules...
>
> It is the misguided focus on too many too simple things from the regulator
> and Congress, without even understanding what a packet is, and enormous
> subsidies for things that don't matter, and great mis-understanding of the
> things that do, that bothers me the most.
>
> Anyway, for 14 years, I have been trying to get bufferbloat fixed,
> universally, and great progress is being made. I felt that with one
> political push like this, it might begin to turn the tide. We are accepting
> signatures on the FCC filing until 2PM EST today.
>
>
> https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4vH4/edit
>
> > On Fri, Dec 1, 2023 at 12:39 PM Tom Mitchell 
> wrote:
> >>
> >> Not sure we need the FCC telling us how to build products or run
> networks.  Seat belts are life-or-death, but bufferbloat is rarely fatal
> ;-)  Let it be a point of differentiation.
> >>
> >> -- Tom
> >>
> >>
> >> On Thu, Nov 30, 2023 at 4:56 PM Dave Taht  wrote:
> >>>
> >>> Over here:
> >>>
> >>> https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-Qmh
> >>> lYRLMBY4vH4/edit
> >>>
> >>> Us bufferbloat folk have been putting together a response to the
> >>> FCC's NOI (notice of inquiry) asking for feedback as to increasing
> >>> the broadband speeds beyond 100/20 Mbit.
> >>>
> >>> "Calls for further bandwidth increases are analogous to calling for
> >>> cars to have top speeds of 100, 200, or 500 miles per hour. Without
> >>> calling also for better airbags, bumpers, brakes, or steering
> >>> wheels, (or roads designed to minimize travel delay), these
> >>> initiatives will fail (and are failing) to meet the needs of present
> >>> and future users of the internet."
> >>>
> >>> Comments (and cites) welcomed also! The text is still somewhat in
> flux...
> >>>
> >>>
> >>> --
> >>> :( 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 ___
> NZNOG mailing list -- nz...@list.waikato.ac.nz To unsubscribe send an
> email to nznog-le...@list.waikato.ac.nz
>
>
>

Re: sigs wanted for a response to the fcc's NOI for faster broadband speeds

[Dave Taht]

On Fri, Dec 1, 2023 at 1:55 PM Mel Beckman  wrote:
>
> bufferbloat is rarely fatal

This task will put me in my grave, sooner rather than later!
>
>
> LOL! I know one person taht may disagree with that :)
>
>  -mel
>
> On Dec 1, 2023, at 9:41 AM, Tom Mitchell  wrote:
>
> 
> Not sure we need the FCC telling us how to build products or run networks.  
> Seat belts are life-or-death, but bufferbloat is rarely fatal ;-)  Let it be 
> a point of differentiation.
>
> -- Tom
>
>
> On Thu, Nov 30, 2023 at 4:56 PM Dave Taht  wrote:
>>
>> Over here:
>>
>> https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4vH4/edit
>>
>> Us bufferbloat folk have been putting together a response to the FCC's
>> NOI (notice of inquiry) asking for feedback as to increasing the
>> broadband speeds beyond 100/20 Mbit.
>>
>> "Calls for further bandwidth increases are analogous to calling for
>> cars to have top speeds of 100, 200, or 500 miles per hour. Without
>> calling also for better airbags, bumpers, brakes, or steering wheels,
>> (or roads designed to minimize travel delay), these initiatives will
>> fail (and are failing) to meet the needs of present and future users
>> of the internet."
>>
>> Comments (and cites) welcomed also! The text is still somewhat in flux...
>>
>>
>> --
>> :( 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

Re: sigs wanted for a response to the fcc's NOI for faster broadband speeds

[William Herrin]

On Thu, Nov 30, 2023 at 4:55 PM Dave Taht  wrote:
> https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4vH4/edit
>
> Comments (and cites) welcomed also! The text is still somewhat in flux...

Hi Dave,

You start off with a decent thesis - beyond 100mbps there really isn't
any difference in capability, not for residential use. Just a
difference in how quickly some tasks complete. It's not like the
difference between 768kbps and 10 mbps where one does streaming video
and conferencing while the other does not.

But then you get lost in latency. Latency is important but it's only
one in a laundry list of things that make the difference between
quality and trash in Internet services.

* Packet loss.

* Service outages. I have a buddy whose phone line has been out for
days four times this year. His ILEC neither wants to maintain the
copper lines nor install fiber that deep in the woods, so they keep
doing mediocre repairs to the infrastructure that don't hold up.

* Incomplete connectivity (e.g. Cogent and IPv6).

Personally, I'd love to see rulemaking to the effect that only folks
with -open- peering policies are eligible for government funds and
contracts. But that's my pet peeve, like latency is yours. And if I
pitch that, it'll rightly be seen as a pet issue.

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: sigs wanted for a response to the fcc's NOI for faster broadband speeds

[Daniel Marks via NANOG]

Yea I’d like to see mandated IPv6 if ISPs want government money, around here an 
IPv4 only ISP won a government contract a while back for res fiber deployment 
and the last I heard from an acquaintance I spoke to over there they are 
planning to stuff the entire city behind a /24 with no upcoming plans to enable 
v6 (but of course you can get your own IP if you pay more).

I’m not a conspiracy theorist but sometimes it feels like some smaller ISPs are 
intentionally not deploying v6 so they can get customers to upgrade to more 
expensive plans for the luxury of *checks notes* not getting rate limited. 

Sent from my iPhone

> On Dec 1, 2023, at 15:41, William Herrin  wrote:
> 
> On Thu, Nov 30, 2023 at 4:55 PM Dave Taht  wrote:
>> https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4vH4/edit
>> 
>> Comments (and cites) welcomed also! The text is still somewhat in flux...
> 
> Hi Dave,
> 
> You start off with a decent thesis - beyond 100mbps there really isn't
> any difference in capability, not for residential use. Just a
> difference in how quickly some tasks complete. It's not like the
> difference between 768kbps and 10 mbps where one does streaming video
> and conferencing while the other does not.
> 
> But then you get lost in latency. Latency is important but it's only
> one in a laundry list of things that make the difference between
> quality and trash in Internet services.
> 
> * Packet loss.
> 
> * Service outages. I have a buddy whose phone line has been out for
> days four times this year. His ILEC neither wants to maintain the
> copper lines nor install fiber that deep in the woods, so they keep
> doing mediocre repairs to the infrastructure that don't hold up.
> 
> * Incomplete connectivity (e.g. Cogent and IPv6).
> 
> Personally, I'd love to see rulemaking to the effect that only folks
> with -open- peering policies are eligible for government funds and
> contracts. But that's my pet peeve, like latency is yours. And if I
> pitch that, it'll rightly be seen as a pet issue.
> 
> Regards,
> Bill Herrin
> 
> 
> 
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

Re: sigs wanted for a response to the fcc's NOI for faster broadband speeds

[Shane Ronan]

Unfortunately from my experience it's usually because the small local ISPs
don't have the resources to understand IPv6, and may be using equipment
generations old that may not support IPv6. It's the large ISPs that don't
want to do it because it would increase their operational costs and require
upgrades to operational systems and they see no new revenue associated.

Shane



On Fri, Dec 1, 2023 at 4:23 PM Daniel Marks via NANOG 
wrote:

> Yea I’d like to see mandated IPv6 if ISPs want government money, around
> here an IPv4 only ISP won a government contract a while back for res fiber
> deployment and the last I heard from an acquaintance I spoke to over there
> they are planning to stuff the entire city behind a /24 with no upcoming
> plans to enable v6 (but of course you can get your own IP if you pay more).
>
> I’m not a conspiracy theorist but sometimes it feels like some smaller
> ISPs are intentionally not deploying v6 so they can get customers to
> upgrade to more expensive plans for the luxury of *checks notes* not
> getting rate limited.
>
> Sent from my iPhone
>
> > On Dec 1, 2023, at 15:41, William Herrin  wrote:
> >
> > On Thu, Nov 30, 2023 at 4:55 PM Dave Taht  wrote:
> >>
> https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4vH4/edit
> >>
> >> Comments (and cites) welcomed also! The text is still somewhat in
> flux...
> >
> > Hi Dave,
> >
> > You start off with a decent thesis - beyond 100mbps there really isn't
> > any difference in capability, not for residential use. Just a
> > difference in how quickly some tasks complete. It's not like the
> > difference between 768kbps and 10 mbps where one does streaming video
> > and conferencing while the other does not.
> >
> > But then you get lost in latency. Latency is important but it's only
> > one in a laundry list of things that make the difference between
> > quality and trash in Internet services.
> >
> > * Packet loss.
> >
> > * Service outages. I have a buddy whose phone line has been out for
> > days four times this year. His ILEC neither wants to maintain the
> > copper lines nor install fiber that deep in the woods, so they keep
> > doing mediocre repairs to the infrastructure that don't hold up.
> >
> > * Incomplete connectivity (e.g. Cogent and IPv6).
> >
> > Personally, I'd love to see rulemaking to the effect that only folks
> > with -open- peering policies are eligible for government funds and
> > contracts. But that's my pet peeve, like latency is yours. And if I
> > pitch that, it'll rightly be seen as a pet issue.
> >
> > Regards,
> > Bill Herrin
> >
> >
> >
> > --
> > William Herrin
> > b...@herrin.us
> > https://bill.herrin.us/
>

Re: sigs wanted for a response to the fcc's NOI for faster broadband speeds

[Brandon Martin]

On 12/1/23 16:45, Shane Ronan wrote:
Unfortunately from my experience it's usually because the small local 
ISPs don't have the resources to understand IPv6, and may be using 
equipment generations old that may not support IPv6. It's the large ISPs 
that don't want to do it because it would increase their operational 
costs and require upgrades to operational systems and they see no new 
revenue associated.


Honestly, how old is your equipment at this point to not support IPv6 at 
all or usably in the data plane and in-band parts of the control plane? 
I wouldn't think it's even commercially relevant anymore.  Pretty much 
anything L3 with at least 10Gb ports probably has support for most 
things relevant to a small local ISP.


You might be missing some niceties, but even some new stuff is missing 
those.  The big one I've seen is a nice way to handle DHCPv6-PD 
delegations without having to resort to using BGP to inject the routes 
(looking at you, Extreme SLX).


--
Brandon Martin

Re: sigs wanted for a response to the fcc's NOI for faster broadband speeds

[Tom Samplonius]

> https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4vH4/edit
> 
> Us bufferbloat folk have been putting together a response to the FCC's
> NOI (notice of inquiry) asking for feedback as to increasing the
> broadband speeds beyond 100/20 Mbit.


  The era of “buffer bloat” has passed.  Buffer bloat is just about jitter, and 
jitter mitigation is just better now.

  I don’t think jitter needs to be part of public policy.


Tom

Re: sigs wanted for a response to the fcc's NOI for faster broadband speeds

[Tom Beecher]

Trying to put technical requirements like this into law and public policy
is an extremely terrible idea. This letter should never be sent.

The regulatory agencies today don't have the manpower or expertise to
adequately enforce the more generic broadband deployment rules. What
fantasy world exists where they have the manpower or expertise to monitor
for and enforce something like this? Hell, there are constant , legitimate
technical discussions between experts on HOW to *properly* monitor things
just like this. We want to have someone at the FCC deciding what that
should look like?

4.4 What the hell? The regulatory agencies should be allocating spectrum,
and making sure it's not used improperly with the rules of allocation.
Making it work 'better' is OUR job in the technical community. Not an FCC
rulemaker.

4.8 There are zero scenarios there should ever be regulatory rules about
device software. In our space (non-ISP) , TONS of people run older versions
of vendor code. Why? The shit DOESN'T WORK RIGHT YET and it causes other
problems. You suggest that regulatory bodies be involved in dictating
anything about this?

The bufferbloat work belongs in the technical area, full stop. Nowhere near
regulatory / legal.

On Thu, Nov 30, 2023 at 7:57 PM Dave Taht  wrote:

> Over here:
>
>
> https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4vH4/edit
>
> Us bufferbloat folk have been putting together a response to the FCC's
> NOI (notice of inquiry) asking for feedback as to increasing the
> broadband speeds beyond 100/20 Mbit.
>
> "Calls for further bandwidth increases are analogous to calling for
> cars to have top speeds of 100, 200, or 500 miles per hour. Without
> calling also for better airbags, bumpers, brakes, or steering wheels,
> (or roads designed to minimize travel delay), these initiatives will
> fail (and are failing) to meet the needs of present and future users
> of the internet."
>
> Comments (and cites) welcomed also! The text is still somewhat in flux...
>
>
> --
> :( My old R&D campus is up for sale: https://tinyurl.com/yurtlab
> Dave Täht CSO, LibreQos
>

Re: sigs wanted for a response to the fcc's NOI for faster broadband speeds

[sronan]

Again, these rules typically only relevant when  you are taking government funding or the government is looking to allocate future funding. Providers who don’t take government funding are welcome to run their networks as they choose.ShaneOn Dec 1, 2023, at 7:35 PM, Tom Beecher  wrote:Trying to put technical requirements like this into law and public policy is an extremely terrible idea. This letter should never be sent. The regulatory agencies today don't have the manpower or expertise to adequately enforce the more generic broadband deployment rules. What fantasy world exists where they have the manpower or expertise to monitor for and enforce something like this? Hell, there are constant , legitimate technical discussions between experts on HOW to *properly* monitor things just like this. We want to have someone at the FCC deciding what that should look like?4.4 What the hell? The regulatory agencies should be allocating spectrum, and making sure it's not used improperly with the rules of allocation. Making it work 'better' is OUR job in the technical community. Not an FCC rulemaker. 4.8 There are zero scenarios there should ever be regulatory rules about device software. In our space (non-ISP) , TONS of people run older versions of vendor code. Why? The shit DOESN'T WORK RIGHT YET and it causes other problems. You suggest that regulatory bodies be involved in dictating anything about this? The bufferbloat work belongs in the technical area, full stop. Nowhere near regulatory / legal. On Thu, Nov 30, 2023 at 7:57 PM Dave Taht  wrote:Over here:

https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4vH4/edit

Us bufferbloat folk have been putting together a response to the FCC's
NOI (notice of inquiry) asking for feedback as to increasing the
broadband speeds beyond 100/20 Mbit.

"Calls for further bandwidth increases are analogous to calling for
cars to have top speeds of 100, 200, or 500 miles per hour. Without
calling also for better airbags, bumpers, brakes, or steering wheels,
(or roads designed to minimize travel delay), these initiatives will
fail (and are failing) to meet the needs of present and future users
of the internet."

Comments (and cites) welcomed also! The text is still somewhat in flux...


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

Re: sigs wanted for a response to the fcc's NOI for faster broadband speeds

[Mike Hammett]

It would be better to keep the government out of it altogether, but that has 
little chance of happening. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Tom Beecher"  
To: "Dave Taht"  
Cc: "NANOG" , "NZNOG" , 
""  
Sent: Friday, December 1, 2023 6:34:49 PM 
Subject: Re: sigs wanted for a response to the fcc's NOI for faster broadband 
speeds 


Trying to put technical requirements like this into law and public policy is an 
extremely terrible idea. This letter should never be sent. 


The regulatory agencies today don't have the manpower or expertise to 
adequately enforce the more generic broadband deployment rules. What fantasy 
world exists where they have the manpower or expertise to monitor for and 
enforce something like this? Hell, there are constant , legitimate technical 
discussions between experts on HOW to *properly* monitor things just like this. 
We want to have someone at the FCC deciding what that should look like? 


4.4 What the hell? The regulatory agencies should be allocating spectrum, and 
making sure it's not used improperly with the rules of allocation. Making it 
work 'better' is OUR job in the technical community. Not an FCC rulemaker. 


4.8 There are zero scenarios there should ever be regulatory rules about device 
software. In our space (non-ISP) , TONS of people run older versions of vendor 
code. Why? The shit DOESN'T WORK RIGHT YET and it causes other problems. You 
suggest that regulatory bodies be involved in dictating anything about this? 


The bufferbloat work belongs in the technical area, full stop. Nowhere near 
regulatory / legal. 


On Thu, Nov 30, 2023 at 7:57 PM Dave Taht < dave.t...@gmail.com > wrote: 


Over here: 

https://docs.google.com/document/d/19ADByjakzQXCj9Re_pUvrb5Qe5OK-QmhlYRLMBY4vH4/edit
 

Us bufferbloat folk have been putting together a response to the FCC's 
NOI (notice of inquiry) asking for feedback as to increasing the 
broadband speeds beyond 100/20 Mbit. 

"Calls for further bandwidth increases are analogous to calling for 
cars to have top speeds of 100, 200, or 500 miles per hour. Without 
calling also for better airbags, bumpers, brakes, or steering wheels, 
(or roads designed to minimize travel delay), these initiatives will 
fail (and are failing) to meet the needs of present and future users 
of the internet." 

Comments (and cites) welcomed also! The text is still somewhat in flux... 


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

Re: sigs wanted for a response to the fcc's NOI for faster broadband speeds

[William Herrin]

On Fri, Dec 1, 2023 at 1:45 PM Shane Ronan  wrote:
> Unfortunately from my experience it's usually because the small local
> ISPs don't have the resources to understand IPv6, and may be using
> equipment generations old that may not support IPv6. It's the large
> ISPs that don't want to do it because it would increase their operational
> costs and require upgrades to operational systems and they see no new
> revenue associated.

Hi Shane,

6rd works well enough, has been around long enough, and doesn't
require any significant equipment upgrades to implement. An ISP who
hasn't at least implemented that much is just being lazy.

Regards,
Bill Herrin



-- 
William Herrin
b...@herrin.us
https://bill.herrin.us/

Re: sigs wanted for a response to the fcc's NOI for faster broadband speeds

[sronan]

Or has no engineer capable of configuring it, or support staff trained to 
handle the issues that will come up.

There are many reasons why providers don’t support v6.

> On Dec 1, 2023, at 11:20 PM, William Herrin  wrote:
> 
> On Fri, Dec 1, 2023 at 1:45 PM Shane Ronan  wrote:
>> Unfortunately from my experience it's usually because the small local
>> ISPs don't have the resources to understand IPv6, and may be using
>> equipment generations old that may not support IPv6. It's the large
>> ISPs that don't want to do it because it would increase their operational
>> costs and require upgrades to operational systems and they see no new
>> revenue associated.
> 
> Hi Shane,
> 
> 6rd works well enough, has been around long enough, and doesn't
> require any significant equipment upgrades to implement. An ISP who
> hasn't at least implemented that much is just being lazy.
> 
> Regards,
> Bill Herrin
> 
> 
> 
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

Re: sigs wanted for a response to the fcc's NOI for faster broadband speeds

[Stephen Satchell]

On 12/1/23 5:27 PM, Mike Hammett wrote:

It would be better to keep the government out of it altogether, but that has 
little chance of happening.



I agree.  But I do have a question: is there a Best Practices RFC for 
setting buffer sizes in the existing corpus?  The Internet community has 
been pretty good at setting reasonable standards and recommendations, so 
a pointer to a BCP or RFC would go much farther to solve the bufferbloat 
problem, as I believe administrators would prefer the "suggestion" 
instead of ham-handed regulation.


But that's just me.  I do know there has been academic research on the 
subject, but don't recall seeing the results published as a practical 
operational RFC.


(And this is very much on-topic for NANOG, as it is about encouraging 
our peers to implement effective operation in their networks, and in 
their connections with others.)