RE: what is acceptible jitter for voip and videoconferencing?

[Brian Turnbow via NANOG]

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

There  are also some opensourced like  lyra from google with v2 released last 
year. 
https://opensource.googleblog.com/2022/09/lyra-v2-a-better-faster-and-more-versatile-speech-codec.html

otoh the voip specifications here  in Italy mandates the use of only g711 and 
g729 for calls between landline providers.
Transcode or use only 729/711 making Killing them softly with quality issues  
sound like a good title for a song.

 
Brian

Re: TACACS+ server recommendations?

[Simon Leinen]

Christopher Morrow writes:
> 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...

Ahem... Cisco supports SSH authentication using *X.509* certificates.
Unfortunately this is not compatible with OpenSSH (the dominant SSH
client implementation we use), which only supports *OpenSSH*
certificates.

Not sure about other vendors, but when we found this out we decided that
this wasn't a workable solution for us.
-- 
Simon.

Re: TACACS+ server recommendations?

[Jim]

On Thu, Sep 21, 2023 at 4:40 AM Simon Leinen  wrote:

>
> Ahem... Cisco supports SSH authentication using *X.509* certificates.
> Unfortunately this is not compatible with OpenSSH (the dominant SSH
>

It's not a great solution, but it is certainly a solution.
The feature exists for some routers/switch models running certain
licenses/images...
an existing 200 NE network is not likely to have the feature 100% available
by accident, though.

On the other hand:  the strategy of using local auth on devices and having
a few local users
with specific privilege levels,  and centralized systems that manage the
ones creds for all
normal day-to-day usage: Storage and frequent automatic rotation of
passwords, and
when an operator needs to login:  the central system authorize a privileged
User to access,

Either "check out" a device using AAA to decide who can check out which
devices,
Or users run their SSH sessions through centralized connection managers
(Acting as a man-in-the-middle authenticating
to devices using its own credentials.  Authorizing user commands proxied
through
the server)  -   Allows AAA  and command authorization to be performed by
the central server.

My understanding is a good number of password manager products exists which
will handle that,
and then the only AAA  which  network devices need to be concerned about
for Authentication and
Authorization is  Basic password auth,  which all equipment supports.   And
the security problems
don't arise so much for using the TACACS+ / Tac_plus service Solely for
Accounting
(in addition to basic remote syslog).

client implementation we use), which only supports *OpenSSH*
> certificates.
>

--
-Jim

Re: what is acceptible jitter for voip and videoconferencing?

[Tom Beecher]

My understanding has always been that 30ms was set based on human
perceptibility. 30ms was the average point at which the average person
could start to detect artifacts in the audio.

On Tue, Sep 19, 2023 at 8:13 PM Dave Taht  wrote:

> 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: TACACS+ server recommendations?

[Christopher Morrow]

On Thu, Sep 21, 2023 at 5:40 AM Simon Leinen  wrote:
>
> Christopher Morrow writes:
> > 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...
>
> Ahem... Cisco supports SSH authentication using *X.509* certificates.

correct, we pointed this out a few times and ... they now also support
ssh-certs.
They also support HIBA extensions (https://github.com/google/hiba) and the
stock hiba-chk which means you could potentially mint a certificate for your
ops user that says: "Simon is authorized to login to DEVICEX only"
(and or others, or not have this check... this is optional, but handy for me)

> Unfortunately this is not compatible with OpenSSH (the dominant SSH
> client implementation we use), which only supports *OpenSSH*
> certificates.

yup, that's what we pointed out to them.. I think their answer was
something like:
  "mumble, we implemented this for a single requesting organization...
we THINK they use it?"

unsure hwo they use it, but.. ok, sure.
now there's openssh cert capability though.
(I admit I can't make search on cisco's site work for me to find what
version introduced this though, sorry)

> Not sure about other vendors, but when we found this out we decided that
> this wasn't a workable solution for us.

it sure wasn't for a long time :(
3 of 4 vendors we deal with support openssh-certificates and hiba...
almost all to the point were
we could actually use it, which is nice. we have some  pains on our
side, they on theirs, but it's
getting almost deployable.

Re: TACACS+ server recommendations?

[Christopher Morrow]

On Thu, Sep 21, 2023 at 6:56 AM Jim  wrote:
...
> My understanding is a good number of password manager products exists which 
> will handle that,
> and then the only AAA  which  network devices need to be concerned about for 
> Authentication and
> Authorization is  Basic password auth,  which all equipment supports.   And 
> the security problems
> don't arise so much for using the TACACS+ / Tac_plus service Solely for 
> Accounting
> (in addition to basic remote syslog).

it's important to recognize that there's not really any protection
(practical protection) from MITM if
you use a passwd with your ssh connection.

A key'd authentication has these protections, as a quirk of the ssh
protocol... (or a design feature if you wish)
A certificate authenticated session has these same protections.

25 Days Until NANOG 89! Pro Tips for Speaking at NANOG + More

[Nanog News]

*Pro Tips for Speaking at NANOG*
*Q & A with NANOG 89 Speaker ISOC's Aftab Siddiqui*

Senior Manager for Internet Technology at Internet Society (ISOC), Aftab
Siddiqui has presented at other conferences; however, he confesses that "no
other conference is as thorough as NANOG" in the submission process.
He will present, "Do We Still Need [Unauth] IRR?" at our next meeting,
NANOG 89 in San Diego 16 - 18 Oct.

*READ MORE *


*Sponsorships Still Available!*

Sign on before 25 Sept. to be included on our NANOG 89 Sponsor's Banner.
Contact Shawn Winstead at swinst...@nanog.org for details.

*Video of the Week*
*Cloud Network Engineering: A Closer Look at a New Career Path w/ Kam
Agahian*

Check out an introduction to the emerging career of a Cloud Network
Engineer.

*WATCH NOW  *

Re: what is acceptible jitter for voip and videoconferencing?

[Eric Kuhnke]

Artifacts in audio are a product of packet loss or jitter resulting in
codec issues issues leading to human subject perceptible audio anomalies,
not so much latency by itself. Two way voice is remarkably NOT terrible on
a 495ms RTT satellite based two-way geostationary connection as long as
there is little or no packet loss.

On Thu, Sep 21, 2023 at 12:47 PM Tom Beecher  wrote:

> My understanding has always been that 30ms was set based on human
> perceptibility. 30ms was the average point at which the average person
> could start to detect artifacts in the audio.
>
> On Tue, Sep 19, 2023 at 8:13 PM Dave Taht  wrote:
>
>> 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: what is acceptible jitter for voip and videoconferencing?

[William Herrin]

On Thu, Sep 21, 2023 at 6:28 AM Tom Beecher  wrote:
> My understanding has always been that 30ms was set based on human 
> perceptibility. 30ms was the average point at which the average person could 
> start to detect artifacts in the audio.

Hi Tom,

Jitter doesn't necessarily cause artifacts in the audio. Modern
applications implement what's called a "jitter buffer." As the name
implies, the buffer collects and delays audio for a brief time before
playing it for the user. This allows time for the packets which have
been delayed a little longer (jitter) to catch up with the earlier
ones before they have to be played for the user. Smart implementations
can adjust the size of the jitter buffer to match the observed
variation in delay so that sound quality remains the same regardless
of jitter.

Indeed, on Zoom I barely noticed audio artifacts for a friend who was
experiencing 800ms jitter. Yes, really, 800ms. We had to quit our
gaming session because it caused his character actions to be utterly
spastic, but his audio came through okay.

The problem, of course, is that instead of the audio delay being the
average packet delay, it becomes the maximum packet delay. You start
to have problems with people talking over each other because when they
start they can't yet hear the other person talking. "Sorry, go ahead.
No, you go ahead."

Regards,
Bill Herrin


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

Re: what is acceptible jitter for voip and videoconferencing?

[Dave Taht]

Thank you all for your answers here, on the poll itself, and for
papers like this one. The consensus seems to be settling around 30ms for
VOIP with a few interesting outliers and viewpoints.

https://scholarworks.gsu.edu/cgi/viewcontent.cgi?article=1043&context=cs_theses

Something that came up in reading that... that I half remember from my
early days of working with VOIP (on asterisk) was that silence suppression
(and comfort noise) that did not send any packets was in general worse than
sending silence (or comfort noise) - for two reasons - one was nat closures,
but the other was that steady stream also helped control congestion and had
less jitter swings.

So in the deployments I was doing then, I universally disabled this feature
on the phones I was using then.

In my mind (particularly in a network that is packet (not byte) buffer
limited), this showed that point, (to an extreme!)

https://www.duo.uio.no/bitstream/handle/10852/45274/1/thesis.pdf

But my question is now, are we doing silence suppression (not sending
packets) on voip nowadays?

On Thu, Sep 21, 2023 at 2:55 PM Eric Kuhnke  wrote:

> Artifacts in audio are a product of packet loss or jitter resulting in
> codec issues issues leading to human subject perceptible audio anomalies,
> not so much latency by itself. Two way voice is remarkably NOT terrible on
> a 495ms RTT satellite based two-way geostationary connection as long as
> there is little or no packet loss.
>
> On Thu, Sep 21, 2023 at 12:47 PM Tom Beecher  wrote:
>
>> My understanding has always been that 30ms was set based on human
>> perceptibility. 30ms was the average point at which the average person
>> could start to detect artifacts in the audio.
>>
>> On Tue, Sep 19, 2023 at 8:13 PM Dave Taht  wrote:
>>
>>> 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
>>>
>>

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

Re: what is acceptible jitter for voip and videoconferencing?

[Dave Taht]

On Thu, Sep 21, 2023 at 3:34 PM William Herrin  wrote:

> On Thu, Sep 21, 2023 at 6:28 AM Tom Beecher  wrote:
> > My understanding has always been that 30ms was set based on human
> perceptibility. 30ms was the average point at which the average person
> could start to detect artifacts in the audio.
>
> Hi Tom,
>
> Jitter doesn't necessarily cause artifacts in the audio. Modern
> applications implement what's called a "jitter buffer." As the name
> implies, the buffer collects and delays audio for a brief time before
> playing it for the user. This allows time for the packets which have
> been delayed a little longer (jitter) to catch up with the earlier
> ones before they have to be played for the user. Smart implementations
> can adjust the size of the jitter buffer to match the observed
> variation in delay so that sound quality remains the same regardless
> of jitter.
>
> Indeed, on Zoom I barely noticed audio artifacts for a friend who was
> experiencing 800ms jitter. Yes, really, 800ms. We had to quit our
> gaming session because it caused his character actions to be utterly
> spastic, but his audio came through okay.
>
> The problem, of course, is that instead of the audio delay being the
> average packet delay, it becomes the maximum packet delay.


Yes. I talked to this point in my apnic session here:
https://blog.apnic.net/2020/01/22/bufferbloat-may-be-solved-but-its-not-over-yet/

I called it "riding the TCP sawtooth"- the compensating voip delay becomes
equal to the maximum size of the buffer, and thus controls the jitter that
way. Sometimes, to unreasonable extents, like 800ms in your example.


> You start
> to have problems with people talking over each other because when they
> start they can't yet hear the other person talking. "Sorry, go ahead.
> No, you go ahead."
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/
>


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

Re: what is acceptible jitter for voip and videoconferencing?

[Michael Thomas]

On 9/21/23 3:31 PM, William Herrin wrote:

On Thu, Sep 21, 2023 at 6:28 AM Tom Beecher  wrote:

My understanding has always been that 30ms was set based on human 
perceptibility. 30ms was the average point at which the average person could 
start to detect artifacts in the audio.

Hi Tom,

Jitter doesn't necessarily cause artifacts in the audio. Modern
applications implement what's called a "jitter buffer." As the name
implies, the buffer collects and delays audio for a brief time before
playing it for the user. This allows time for the packets which have
been delayed a little longer (jitter) to catch up with the earlier
ones before they have to be played for the user. Smart implementations
can adjust the size of the jitter buffer to match the observed
variation in delay so that sound quality remains the same regardless
of jitter.

Indeed, on Zoom I barely noticed audio artifacts for a friend who was
experiencing 800ms jitter. Yes, really, 800ms. We had to quit our
gaming session because it caused his character actions to be utterly
spastic, but his audio came through okay.


When I wrote my first implementation of telnet ages ago, i was both 
amused and annoyed about the go-ahead option. Obviously patterned after 
audio meat-space protocols, but I was never convinced it wasn't a 
solution in search of a problem. I wonder if CDMA was really an 
outgrowth of those protocols?


But it's my impression that gaming is by far more affected by latency 
and thus jitter buffers for voice. Don't some ISP's even cater to gamers 
about latency?


Mike

Re: what is acceptible jitter for voip and videoconferencing?

[sronan]

That’s because symmetrical latency like you see on a satellite connection isn’t an issue at all for audio, it’s the variation or jitter that may cause issues.ShaneOn Sep 21, 2023, at 5:58 PM, Eric Kuhnke  wrote:Artifacts in audio are a product of packet loss or jitter resulting in codec issues issues leading to human subject perceptible audio anomalies, not so much latency by itself. Two way voice is remarkably NOT terrible on a 495ms RTT satellite based two-way geostationary connection as long as there is little or no packet loss. On Thu, Sep 21, 2023 at 12:47 PM Tom Beecher  wrote:My understanding has always been that 30ms was set based on human perceptibility. 30ms was the average point at which the average person could start to detect artifacts in the audio. On Tue, Sep 19, 2023 at 8:13 PM Dave Taht  wrote: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 runningvoip 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.htmlDave Täht CSO, LibreQos