Re: Zayo woes

[Richard Holbo]

Laughing out Loud, really, good views all...
Having been through this a few times.. and being one of those who is now
the one of the hated C level guys..
Much truth is spoken here.  EBITA and size are the issues IMHO in our
current system.
Having been the owner of a few "smallish" retail ISPs in the west.. I can
say with certainty that size is an issue.  in the world of today a
small/medium ISP can do OK, but can never access the funds or resources
necessary to actually be a long term survivor.  To that end we look at
sources of money that require us to sell a majority interest in our company
to make it to the next level, that and exhaustion from staying awake nights
wondering how to make next payroll because we spent a couple million on new
gear.
This money seeking then comes with an interview system where we court the
guys with money and they court us.. The outcome is always iffy.  You can
partner with money that has a good plan or one that sucks (done both).
Even if you get good money, you will suffer from culture issues.  Small
ISP's tend to focus on the people and the customers, the larger you get the
more important the money becomes (EBITA) which for a lot of the employees
is, well, hard.
But staying small in general = extinction so  you do what you do to keep
employees working (at least that's what I tell myself).
Good views all, and I totally agree with @Matthew Petach miracles
statement.. I'm no longer that guy, but I like to think I was in the past,
and I've got a bunch of them working for me now, so I try really hard to
appreciate it and to recognize that that is what is happening, I fight for
the money to do it as right as possible.. but I do depend on  you
miracle workers.

/thanks
/rh

On Wed, Sep 20, 2023 at 9:30 AM Matthew Petach 
wrote:

>
>
> On Tue, Sep 19, 2023 at 12:21 PM Mike Hammett  wrote:
>
>> Well sure, and I would like to think (probably mistakenly) that just no
>> one important enough (to the money people) made the money people that these
>> other things are *REQUIRED* to make the deal work.
>>
>> Obviously, people lower on the ladder say it all of the time, but the
>> important enough money people probably don't consider those people
>> important enough to listen to.
>>
>
>
> Not quite.
>
> It's more of what Mark said:
>
> "  I blame this on the success of how well we have built the Internet
> with whatever box and tool we have, as network engineers."
>
> I have worked time and time again with absolute miracle workers in the
> networking field.
> They say over and over again "to make this work, we need $X M to get the
> right hardware", even directly to the CFO.
>
> They get handed a roll of duct tape, some baling wire, a used access point
> and a $25 gift card from Office Depot, and they turn it into a functional
> BGP-speaking backbone, because that's what they're good at.
>
> The CFO and the rest of the executives that said "no" to the request for
> $X M to make the integration work properly pat themselves on the back,
> saying "see, we knew they didn't really NEED that money to make it work."
>
> A year down the line, customers are posting to NANOG wondering why things
> are going to hell in a handbasket at ISP A, as the BGP-speaking access
> point with some duct tape, baling wire, and SFPs purchased from Office
> Depot that ties the two networks together starts failing.
>
> As network engineers, we collectively set ourselves up for this by being
> so damn good at pulling miracles out of our backside to keep things running.
> We've effectively been training our executives that if they habitually
> turn down our requests for resources, we'll still find some way of making
> things work.
>
> We pride ourselves on being able to keep a dozen spinning plates going
> like a circus performer, without letting any of them crash to the floor.
>
> It's a hard thing to do, but one lesson I've taught junior network
> engineers of all ages is that sometimes, you have to step back, and watch a
> plate smash into the floor, *even if you could have rescued it*, if it
> seems like that's the only way your executive team will understand that if
> requests for necessary resources are denied, there will be operational
> impacts.
>
> Now, it's not something you should do lightly, and not something to do
> without first working with the executives to understand why the resource
> request is being denied.
> If you are working at a startup, and the money is running out, and the
> company is one step ahead of the creditors, probably not the time to put
> the foot down and intentionally let things crash and burn.
>
> But if the company is doing well, has the money, and the executives just
> want the numbers to look good for wall street analysts, then it's time to
> pause the miracle working, and help them understand that they cannot simply
> expect you to pull a miracle out of your backside every time, just so they
> can look good.
>
> If we continue to pull off miracles after telling executives 

HCX MTU

[David Ratkay]

Anybody work with VMWare HCX having weird MTU issues? Can provide more info
but just curious

Re: TACACS+ server recommendations?

[Drikus Brits]

from a commercial perspective, we've been using Radiator for the last
~7 yearsbeen working really well, super flexible in terms of user
group permissions, authorized commands etc + the upside for us was
logging auth logs to SQL, both authentication and authorization
logsit's primarily aimed as a radius product but has excellent
tacacs daemon capabilities.

On Thu, Sep 21, 2023 at 1:12 AM Bryan Holloway  wrote:
>
> Ah, the good old days when I could download the latest tac_plus code
> from the Cisco FTP site, compile it, and off I go.
>
> But I digress.
>
> Curious if there are any operators out there that have a good
> recommendation on a lightweight TACACS+ server for ~200 NEs and
> access-control for 20-30 folks. Nothing too special, but some sort of
> simple command-control auth would be nice.
>
> Open-source is fine ... we've been looking at commercial options, but
> they're all pretty pricey and have way more features than we need.
>
> Thank you all in advance!
>
> - bryan

Re: TACACS+ server recommendations?

[Christopher Morrow]

On Wed, Sep 20, 2023 at 1:22 PM Jim  wrote:
>
> Router operating systems still typically use only passwords with
> SSH, then those devices send the passwords over that insecure channel.  I 
> have yet to
> see much in terms of routers capable to Tacacs+ Authorize  users based on  
> users'
> openSSH certificate, Public key id,  or  ed2559-sk security key id, etc.

There is active work with vendors (3 or 4 of the folk you may even
use?) to support
ssh with ssh-certificates, I believe this mostly works today, though
configuring it and
distributing your ssh-ca-cert may be fun...

There are also fairly clear paths to get ssh-keys (rsa, ecdsa) working
for user-auth on those
same 4 vendors.

you will, of course, want some method to manage user-owned-key-material and
distribution/rotation of that material to the network. You CAN enable
'key authentication' and
have tac+ authorization/accounting still on the numbered vendors from
above as well.

-chris

8830 Complex Drive Datacenter in San Diego - Anyone Else Affected

[Norman Jester]

Several carriers went down around 7am this morning, all tied to
a datacenter in San Diego that has apparently shut down. Sad to
see that place go, good guys ran it but there are several carriers that
bit the bullet on us today due to that place closing down. Seems every
one of them is grasping to get their connections migrated out and customers
back online. We do not have gear there but I guess some of our carriers did.
Lots of dark fiber enters there from several providers.
Thank the lord for path diversity. :-)

Norman
Mexico Internet Exchange
619-319-7055 (I prefer WhatsApp or Text if you do too.)

Re: TACACS+ server recommendations?

[Douglas Hirata de Moura]

Hi Bryan,

https://tacacsgui.com/ it might be a good fit for you.

Em qua., 20 de set. de 2023 às 12:10, Bryan Holloway 
escreveu:

> Ah, the good old days when I could download the latest tac_plus code
> from the Cisco FTP site, compile it, and off I go.
>
> But I digress.
>
> Curious if there are any operators out there that have a good
> recommendation on a lightweight TACACS+ server for ~200 NEs and
> access-control for 20-30 folks. Nothing too special, but some sort of
> simple command-control auth would be nice.
>
> Open-source is fine ... we've been looking at commercial options, but
> they're all pretty pricey and have way more features than we need.
>
> Thank you all in advance!
>
> - bryan
>

Re: TACACS+ server recommendations?

[Warren Kumari]

On Wed, Sep 20, 2023 at 10:22 AM, Jim  wrote:

> On Wed, Sep 20, 2023 at 11:16 AM Mike Lewinski via NANOG 
> wrote:
>
>> > https://www.shrubbery.net/tac_plus/
>> That tac_plus has python 2 dependencies and so has been removed from
>> Debian packages. That's not surprising given the last update was 2015 and
>> Python 2 was EOL in 2020: https://www.python.org/doc/sunset-python-2/
>
> Currently I favor this one which is still being actively developed:
>> https://www.pro-bono-publico.de/projects/tac_plus.html
>>
>
> Yes.   Well, on the plus side the TACACS protocol has not really changed
> in 30 years,
> Even the 2015 code could work provided you can compile its dependencies
> from sources, right...
>
> On the downside, for the command authorization use:
> TACACS+ provides little protection for messages between client and server;
>
> The protocol's MD5 crypto is so weak that routers using TACACS+ for
> authentication
> might as well just be piping over user credentials in the clear: it's
> barely any better.
>


Yes, but there is current work in the IETF OpsAWG WG to help address this:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-tacacs-tls13/

This work was actually started many years ago, but got sidetracked — there
was no published standard for TACACS, and so we first published RFC8907 -
"The Terminal Access Controller Access-Control System Plus (TACACS+)
Protocol" , and this new
document largely says "Now just do that over TLS! kthxbye…"

Hopefully this draft will progress soon…
W


> Router operating systems still typically use only passwords with
> SSH, then those devices send the passwords over that insecure channel.  I
> have yet to
> see much in terms of routers capable to Tacacs+ Authorize  users based on
> users'
> openSSH certificate, Public key id,  or  ed2559-sk security key id, etc.
>
> In short..  unless you got a VPN or a dedicated secure link from every
> single device to
> its Tacacs server or an Experimental   implementation of TACACS+ over  TLS:
> I would suggest consider Using tools or scripts to distribute users and
> Authorizing configurations to
> devices as local authorization through secure protocols as favorable to
> those network authentication systems
> that transmit sensitive decisions and user data across the network using
> Insecure protocols.
>
> --
> -Jim
>

Web traffic routing

[Sami Joseph]

Hi,

There's an online service that does fraud detection by forwarding web
traffic to their platform before sending it to its destination.

They claim they do it by one of two methods:

1) Traffic is routed to our Cloud via DNS for dynamic async or sync
processing before being proxied to the customer’s website or API.

2) Traffic is mirrored or routed to our ] Cloud via serverless functions in
Cloudflare, Fastly, Akamai, or AWS. Routed traffic is proxied to our
customer’s website or API.

If anyone can point me to how these two work, i'd appreciate it.

Also, any potential issues related to performance.

Thanks,
Sam

Re: TACACS+ server recommendations?

[Jim]

On Wed, Sep 20, 2023 at 11:16 AM Mike Lewinski via NANOG 
wrote:

> > https://www.shrubbery.net/tac_plus/
> That tac_plus has python 2 dependencies and so has been removed from
> Debian packages. That's not surprising given the last update was 2015 and
> Python 2 was EOL in 2020: https://www.python.org/doc/sunset-python-2/

Currently I favor this one which is still being actively developed:
> https://www.pro-bono-publico.de/projects/tac_plus.html


Yes.   Well, on the plus side the TACACS protocol has not really changed in
30 years,
Even the 2015 code could work provided you can compile its dependencies
from sources, right...

On the downside, for the command authorization use:
TACACS+ provides little protection for messages between client and server;

The protocol's MD5 crypto is so weak that routers using TACACS+ for
authentication
might as well just be piping over user credentials in the clear: it's
barely any better.

Router operating systems still typically use only passwords with
SSH, then those devices send the passwords over that insecure channel.  I
have yet to
see much in terms of routers capable to Tacacs+ Authorize  users based on
users'
openSSH certificate, Public key id,  or  ed2559-sk security key id, etc.

In short..  unless you got a VPN or a dedicated secure link from every
single device to
its Tacacs server or an Experimental   implementation of TACACS+ over  TLS:
I would suggest consider Using tools or scripts to distribute users and
Authorizing configurations to
devices as local authorization through secure protocols as favorable to
those network authentication systems
that transmit sensitive decisions and user data across the network using
Insecure protocols.

-- 
-Jim

Re: Zayo woes

[Matthew Petach]

On Tue, Sep 19, 2023 at 12:21 PM Mike Hammett  wrote:

> Well sure, and I would like to think (probably mistakenly) that just no
> one important enough (to the money people) made the money people that these
> other things are *REQUIRED* to make the deal work.
>
> Obviously, people lower on the ladder say it all of the time, but the
> important enough money people probably don't consider those people
> important enough to listen to.
>


Not quite.

It's more of what Mark said:

"  I blame this on the success of how well we have built the Internet with
whatever box and tool we have, as network engineers."

I have worked time and time again with absolute miracle workers in the
networking field.
They say over and over again "to make this work, we need $X M to get the
right hardware", even directly to the CFO.

They get handed a roll of duct tape, some baling wire, a used access point
and a $25 gift card from Office Depot, and they turn it into a functional
BGP-speaking backbone, because that's what they're good at.

The CFO and the rest of the executives that said "no" to the request for $X
M to make the integration work properly pat themselves on the back, saying
"see, we knew they didn't really NEED that money to make it work."

A year down the line, customers are posting to NANOG wondering why things
are going to hell in a handbasket at ISP A, as the BGP-speaking access
point with some duct tape, baling wire, and SFPs purchased from Office
Depot that ties the two networks together starts failing.

As network engineers, we collectively set ourselves up for this by being so
damn good at pulling miracles out of our backside to keep things running.
We've effectively been training our executives that if they habitually turn
down our requests for resources, we'll still find some way of making things
work.

We pride ourselves on being able to keep a dozen spinning plates going like
a circus performer, without letting any of them crash to the floor.

It's a hard thing to do, but one lesson I've taught junior network
engineers of all ages is that sometimes, you have to step back, and watch a
plate smash into the floor, *even if you could have rescued it*, if it
seems like that's the only way your executive team will understand that if
requests for necessary resources are denied, there will be operational
impacts.

Now, it's not something you should do lightly, and not something to do
without first working with the executives to understand why the resource
request is being denied.
If you are working at a startup, and the money is running out, and the
company is one step ahead of the creditors, probably not the time to put
the foot down and intentionally let things crash and burn.

But if the company is doing well, has the money, and the executives just
want the numbers to look good for wall street analysts, then it's time to
pause the miracle working, and help them understand that they cannot simply
expect you to pull a miracle out of your backside every time, just so they
can look good.

If we continue to pull off miracles after telling executives that
additional resources are required, it's no wonder they don't take the
requests as seriously as they should.  ^_^;

Matt




> --
> *From: *"Mark Tinka" 
> *To: *nanog@nanog.org
> *Sent: *Tuesday, September 19, 2023 10:28:26 AM
> *Subject: *Re: Zayo woes
>
>
>
> On 9/19/23 16:48, Mike Hammett wrote:
>
> As someone that has been planning to be in the acquiring seat for a while
> (but yet to do one), I've consistently passed to the money people that
> there's the purchase price and then there's the % on top of that for
> equipment, contractors, etc. to integrate, improve, optimize future
> cashflow, etc. those acquisitions with the rest of what we have.
>
>
> I blame this on the success of how well we have built the Internet with
> whatever box and tool we have, as network engineers.
>
> The money people assume that all routers are the same, all vendors are the
> same, all software is the same, and all features are easily deployable. And
> that all that is possible if you can simply do a better job finding the
> cheapest box compared to your competition.
>
> In general, I don't fancy nuance when designing for the majority. But with
> acquisition and integration, nuance is critical, and nuance quickly shows
> that the acquisition was either underestimated, or not worth doing at all.
>
> Mark.
>
>
>

Re: what is acceptible jitter for voip and videoconferencing?

[Saku Ytti]

On Wed, 20 Sept 2023 at 19:06, Chris Boyd  wrote:

> We run Teams Telephony in $DAYJOB, and it does use SILK.
>
> https://learn.microsoft.com/en-us/microsoftteams/platform/bots/calls-and-meetings/real-time-media-concepts

Looks like codecs still are rapidly evolving in walled gardens. I just
learned about 'Satin'.

https://en.wikipedia.org/wiki/Satin_(codec)

https://ibb.co/jfrD6yk - notice 'payload description' from Teams admin
portal. So at least in some cases Teams switches from Silk to Satin,
wiki suggests 1on1 only, but I can't confirm or deny this.

--
  ++ytti

Re: TACACS+ server recommendations?

[Mike Lewinski via NANOG]

> https://www.shrubbery.net/tac_plus/ 

That tac_plus has python 2 dependencies and so has been removed from Debian 
packages. That's not surprising given the last update was 2015 and Python 2 was 
EOL in 2020: https://www.python.org/doc/sunset-python-2/

Currently I favor this one which is still being actively developed:

https://www.pro-bono-publico.de/projects/tac_plus.html

Re: what is acceptible jitter for voip and videoconferencing?

[Chris Boyd]

> On Sep 20, 2023, at 2:46 AM, Saku Ytti  wrote:
> 
> skype uses Silk
> (maybe teams too?).  

We run Teams Telephony in $DAYJOB, and it does use SILK.

https://learn.microsoft.com/en-us/microsoftteams/platform/bots/calls-and-meetings/real-time-media-concepts

Re: TACACS+ server recommendations?

[Warren Kumari]

On Wed, Sep 20, 2023 at 8:09 AM, Bryan Holloway  wrote:

> Ah, the good old days when I could download the latest tac_plus code from
> the Cisco FTP site, compile it, and off I go.
>


You might be thinking of the Shrubbery one —
https://www.shrubbery.net/tac_plus/

There are newer, fancier, etc ones - but this Just Works.
W



> But I digress.
>
> Curious if there are any operators out there that have a good
> recommendation on a lightweight TACACS+ server for ~200 NEs and
> access-control for 20-30 folks. Nothing too special, but some sort of
> simple command-control auth would be nice.
>
> Open-source is fine ... we've been looking at commercial options, but
> they're all pretty pricey and have way more features than we need.
>
> Thank you all in advance!
>
> - bryan
>

Re: TACACS+ server recommendations?

[Jeff Moore]

We have also used https://www.shrubbery.net/tac_plus/ for some time as
well. Great product!

JM



On Wed, Sep 20, 2023 at 8:15 AM Mark Tinka  wrote:

>
>
> On 9/20/23 17:09, Bryan Holloway wrote:
>
> > Ah, the good old days when I could download the latest tac_plus code
> > from the Cisco FTP site, compile it, and off I go.
> >
> > But I digress.
> >
> > Curious if there are any operators out there that have a good
> > recommendation on a lightweight TACACS+ server for ~200 NEs and
> > access-control for 20-30 folks. Nothing too special, but some sort of
> > simple command-control auth would be nice.
> >
> > Open-source is fine ... we've been looking at commercial options, but
> > they're all pretty pricey and have way more features than we need.
> >
> > Thank you all in advance!
>
> [root@host /home/tinka]# cd /usr/ports/net/tac
> tac_plus4/ tacacs/
> [root@host /home/tinka]#
>
> They work just fine.
>
> These are on FreeBSD, but I am sure they will compile on Linux too.
>
> Mark.
>

Re: TACACS+ server recommendations?

[Mark Tinka]

On 9/20/23 17:39, Jeff Moore wrote:

We have also used https://www.shrubbery.net/tac_plus/ for some time as 
well. Great product!


Yes, that's one of the ones in the FreeBSD ports.

Works very well.

Mark.

Re: TACACS+ server recommendations?

[Mark Tinka]

On 9/20/23 17:09, Bryan Holloway wrote:

Ah, the good old days when I could download the latest tac_plus code 
from the Cisco FTP site, compile it, and off I go.


But I digress.

Curious if there are any operators out there that have a good 
recommendation on a lightweight TACACS+ server for ~200 NEs and 
access-control for 20-30 folks. Nothing too special, but some sort of 
simple command-control auth would be nice.


Open-source is fine ... we've been looking at commercial options, but 
they're all pretty pricey and have way more features than we need.


Thank you all in advance!


[root@host /home/tinka]# cd /usr/ports/net/tac
tac_plus4/ tacacs/
[root@host /home/tinka]#

They work just fine.

These are on FreeBSD, but I am sure they will compile on Linux too.

Mark.

TACACS+ server recommendations?

[Bryan Holloway]

Ah, the good old days when I could download the latest tac_plus code 
from the Cisco FTP site, compile it, and off I go.


But I digress.

Curious if there are any operators out there that have a good 
recommendation on a lightweight TACACS+ server for ~200 NEs and 
access-control for 20-30 folks. Nothing too special, but some sort of 
simple command-control auth would be nice.


Open-source is fine ... we've been looking at commercial options, but 
they're all pretty pricey and have way more features than we need.


Thank you all in advance!

- bryan

RE: what is acceptible jitter for voip and videoconferencing?

[Howard, Lee]

I think it all goes back to the earliest MOS tests ("Hold up the number of 
fingers for how good the sound is") and every once in a while somebody actually 
does some testing to look for correlations.

Thought it's 15 years old, I like this thesis for the writer's reporting: 
https://scholarworks.gsu.edu/cgi/viewcontent.cgi?article=1043=cs_theses

In particular, this table shows the correlation, and is consistent with what I 
would expect.
[cid:image001.png@01D9EBA9.A25944E0]

Lee


From: NANOG  On Behalf 
Of Dave Taht
Sent: Tuesday, September 19, 2023 8:12 PM
To: NANOG 
Subject: what is acceptible jitter for voip and videoconferencing?

This message is from an EXTERNAL SENDER - be CAUTIOUS, particularly with links 
and attachments.


Dear nanog-ers:

I go back many, many years as to baseline numbers for managing voip networks, 
including things like CISCO LLQ, diffserv, fqm prioritizing vlans, and running
voip networks entirely separately... I worked on codecs, such as oslec, and 
early sip stacks, but that was over 20 years ago.

The thing is, I have been unable to find much research (as yet) as to why my 
number exists. Over here I am taking a poll as to what number is most correct 
(10ms, 30ms, 100ms, 200ms),

https://www.linkedin.com/feed/update/urn:li:ugcPost:7110029608753713152/

but I am even more interested in finding cites to support various viewpoints, 
including mine, and learning how slas are met to deliver it.

--
Oct 30: https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html
Dave Täht CSO, LibreQos

Re: Zayo woes

[Mark Tinka]

On 9/19/23 18:05, Mike Hammett wrote:

Some of it is scale-related. Someone's operating just fine at the size 
they are, but the next order of magnitude larger enjoys many benefits 
from that size, but it takes either A) luck or B) the right skills to 
be able to move up to get those benefits. In terms of network 
operators, there's a big difference between a company of 1 and a 
company of 2. Again a big difference between a company of 2 and a 
company of 10. Another big difference between a company of 10 and a 
company of..  I dunno, 100?



1G waves and 100G waves aren't *THAT* different in price anymore. 
However, if 1 is doing you just fine, the much better cost per bit of 
100 won't do you a darn bit of good and will probably hurt. The hurt 
is not only due to the higher MRC, but now the higher NRC for 
equipment with 100G interfaces. If you can put enough bits on the line 
to make it worth it, you've got yourself tremendous advantage. The 
acquisition pays for itself in marginally higher costs for much higher 
revenue.


The company may have been doing just fine before, but couldn't afford 
the move up to 10 or 100 because their present market couldn't justify 
it and the larger market wasn't obtainable until they had it. Catch 22 
that can't really be overcome by most. Enter M Someone just can't 
get to the next level they need to compete with those that can.


I'm talking about companies of relatively equal size and influence.

It's all benefit for smaller companies, even if it may be at the cost of 
the larger one.


Mark.

Re: Zayo woes

[Mark Tinka]

On 9/19/23 17:54, Mike Hammett wrote:

Well sure, and I would like to think (probably mistakenly) that just 
no one important enough (to the money people) made the money people 
that these other things are *REQUIRED* to make the deal work.


Obviously, people lower on the ladder say it all of the time, but the 
important enough money people probably don't consider those people 
important enough to listen to.


The ISP world is not a normal market place :-).

Mark.

Re: what is acceptible jitter for voip and videoconferencing?

[Saku Ytti]

On Wed, 20 Sept 2023 at 03:15, Dave Taht  wrote:

> I go back many, many years as to baseline numbers for managing voip networks, 
> including things like CISCO LLQ, diffserv, fqm prioritizing vlans, and running
> voip networks entirely separately... I worked on codecs, such as oslec, and 
> early sip stacks, but that was over 20 years ago.

I don't believe LLQ has utility in hardware based routers, packets
stay inside hardware based routers single digit microseconds with
nanoseconds of jitter. For software based devices, I'm sure the
situation is different.
Practical example, tier1 network running 3 vendors, with no LLQ can go
across the globe with lower jitter (microseconds) than I can ping my
M1 laptop 127.0.0.1, because I have to do context switches, the
network does not. This is in the BE queue measured in real operation
under long periods, without any engineering effort to try to achieve
low jitter.

> The thing is, I have been unable to find much research (as yet) as to why my 
> number exists. Over here I am taking a poll as to what number is most correct 
> (10ms, 30ms, 100ms, 200ms),

I know there are academic papers as well as vendor graphs showing the
impact of jitter on quality.  Here is one:
https://scholarworks.gsu.edu/cgi/viewcontent.cgi?article=1043=cs_theses
- this appears to roughly say '20ms' G711 is fine. But I'm sure this
is actually very complex to answer well, and I'm sure choice of codec
greatly impacts the answer, like whatsapp uses Opus, skype uses Silk
(maybe teams too?).  And there are many more rare/exotic codecs
optimised for very specific scenarios, like massive packet loss.

-- 
  ++ytti