That’s why you do QoS between the customer’s packets not every packet.
> On 10 Jul 2019, at 12:46 am, Steve Mikulasik via NANOG
> wrote:
>
> Even if QoS on the Internet was possible it would be destroyed by everyone
> marking all their traffic with the highest priority to get the best
>
:How do you deal with QoS for Office365, since the IPs are subject to changes ?
How often is the data in:
https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges
https://docs.microsoft.com/en-us/office365/enterprise/office-365-ip-web-service
out of date?
-Mike
--
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
All,
Verisign is in the process of increasing the size and strength of
the DNSSEC Zone Signing Keys (ZSKs) for the top-level domains that
it operates. As part of this process, the ZSK for the .ARPA zone
will be increased in size from 1024 to 2048
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
All,
Verisign is in the process of increasing the size and strength of
the DNSSEC Zone Signing Keys (ZSKs) for the top-level domains that
it operates. As part of this process, the ZSK for the .NET zone
will be increased in size from 1024 to 1280
> On Jul 9, 2019, at 9:19 AM, Mark Tinka wrote:
>
>
>
>> On 9/Jul/19 16:18, Ross Tajvar wrote:
>> I think the difficulty lies in appropriately marking the traffic. Like
>> Joe said, the IPs are always changing.
>
> Does anyone know if they are reasonably static in an Express Route scenario?
On Tue, Jul 9, 2019 at 10:02 AM Tom Beecher wrote:
>>
>> At a previous employer (AOL, doing VoIP for customer service / call
>> centers, ~2004) we had a number of contractual agreements with
>> multiple providers to honor our QoS markings -- as far as I could tell
>> (marking test traffic under
The agenda for the SHAKEN/STIR robocall summit was published today.
Date: Thursday, July 11, 2019
Time: 9:30 a.m. to 3:30 p.m.
Location: Commission Meeting Room at FCC Headquarters
It will also be live-streamed on the FCC web site.
Have you looked into Cisco’s SD-AVC? Also with the o365 connector?
https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/avc/sd-avc/2-1-0/ug/sd-avc-2-1-0-ug.pdf
On Jul 2, 2019, at 17:18, Joe Yabuki wrote:
Hi all,
How do you deal with QoS for Office365, since the IPs are subject to changes ?
I looked back into work email from back then and I see where I made my
mistake. I had misread the 7.4 change where they added the option for allow
IPQoS=none , apparently my brain just skipped the word 'option', and it
stuck in my brain as the default behavior being 'none'. That's
embarrassing,
On 9/Jul/19 17:06, Joel Jaeggli wrote:
> Express route peering with 12076 gives you more specific routes then you
> would otherwise see from 8075 (a /13 becomes a bunch of 17s etc) . it also
> gives you control over what region / application is exported to you.
As I had assumed.
But of
On Tue, 9 Jul 2019 at 18:50, Tom Beecher wrote:
> I respectfully just don't agree on that. In my view, software should default
> to not setting those bits to anything by default, but should have
> configuration options that allow them to be set if required. Every network is
> different, and
On 09/07/2019 16:27, Jay Ford wrote:
On Tue, 9 Jul 2019, Mark Tinka wrote:
On 9/Jul/19 16:18, Ross Tajvar wrote:
I think the difficulty lies in appropriately marking the traffic. Like
Joe said, the IPs are always changing.
Does anyone know if they are reasonably static in an Express Route
I respectfully just don't agree on that. In my view, software should
default to not setting those bits to anything by default, but should have
configuration options that allow them to be set if required. Every network
is different, and making assumptions based on RFC SHOULD's is an
unfortunate
Hello,
I released the first major version of rVRRPd, an open source and
RFC3768-compliant VRRPv2 daemon. It actually only supports Linux but I
will soon be adding support for additional operating systems and platforms.
rVRRPd was born from my desire to develop skills in system development.
I
On Tue, 9 Jul 2019, Mark Tinka wrote:
On 9/Jul/19 16:18, Ross Tajvar wrote:
I think the difficulty lies in appropriately marking the traffic. Like
Joe said, the IPs are always changing.
Does anyone know if they are reasonably static in an Express Route scenario?
At least sometimes M$ says
Hey Tom
> That's already been happening. OpenSSH pulled that stunt in 7.8.
OpenSSH always coloured interactive and non-interactive SSH. They just
used original TOS definition, which no one has used in the field, not
in the last 20 years at any rate. And which devices actually cannot
even match
back on track to stir/shaken
would a service provider also need to implement this? or its for the big
carriers to do ?
On Mon, Jul 8, 2019 at 11:17 PM Michael Thomas wrote:
>
> On 7/8/19 7:11 PM, Christopher Morrow wrote:
> > when do we get back to stir/shaken?
>
> that would be nice. i have a
That's already been happening. OpenSSH pulled that stunt in 7.8.
https://www.openssh.com/txt/release-7.8
ssh(1)/sshd(8): the default IPQoS used by ssh/sshd has changed.
They will now use DSCP AF21 for interactive traffic and CS1 for
bulk. For a detailed rationale, please see the commit
On Tue, 9 Jul 2019 at 17:37, Valdis Klētnieks wrote:
> But how did you verify they "worked" as far as actually dropping packets off
> the correct flow (especially since if you have a high-priority QoS, the flow
> that
> loses may be some other customer's flow)?
By congesting queues and
> On Jul 9, 2019, at 07:19, Mark Tinka wrote:
>
>
>
> On 9/Jul/19 16:18, Ross Tajvar wrote:
>> I think the difficulty lies in appropriately marking the traffic. Like
>> Joe said, the IPs are always changing.
>
> Does anyone know if they are reasonably static in an Express Route scenario?
On 9/Jul/19 16:46, Steve Mikulasik wrote:
> Even if QoS on the Internet was possible it would be destroyed by everyone
> marking all their traffic with the highest priority to get the best
> performance. Tragedy of the commons.
I kind of like the Internet the way it is. The best-effort
On 9/Jul/19 16:37, Valdis Kl ē tnieks wrote:
> I'll bite.
>
> It's one thing to verify that no routers molested the QoS bits along the
> packet path.
>
> But how did you verify they "worked" as far as actually dropping packets off
> the correct flow (especially since if you have a high-priority
Even if QoS on the Internet was possible it would be destroyed by everyone
marking all their traffic with the highest priority to get the best
performance. Tragedy of the commons.
-Original Message-
From: NANOG On Behalf Of Mark Tinka
Sent: Monday, July 8, 2019 10:40 AM
To:
Hi all,
Thanks for your replies,
I'll rephrase just to clarify, our aim is to do QoS within our extended LAN
(From remote sites to the Datacenter using the MPLS provider as transit) -
and we can't use DIA for a security reasons...
So arguably, we still need to mark/queue/police packets at the
On Tue, 09 Jul 2019 17:16:52 +0300, Saku Ytti said:
> In previous life working with L3 MPLS VPN with deliveries far
> exceeding on-net size we bought access from partners and had QoS
> contracts in place, which were tested and enforced and they worked
> after some ironing during field trials.
On 9/Jul/19 16:23, Brandon Martin wrote:
>
> To be fair, there are some folks who operate national or global big-I
> Internet IP networks that do guarantee QoS as long as you stay on
> their network.
Yes, which is the point... as long as the traffic is on-net, you can
guarantee things.
On 9/Jul/19 16:16, Saku Ytti wrote:
> In previous life working with L3 MPLS VPN with deliveries far
> exceeding on-net size we bought access from partners and had QoS
> contracts in place, which were tested and enforced and they worked
> after some ironing during field trials.
> Usually
On 7/8/19 4:01 PM, adamv0...@netconsultings.com wrote:
And yet the SD-WAN promising MPLS experience over the internet and other BS
sells like crazy;)
To be fair, there are some folks who operate national or global big-I
Internet IP networks that do guarantee QoS as long as you stay on their
On 9/Jul/19 16:18, Ross Tajvar wrote:
> I think the difficulty lies in appropriately marking the traffic. Like
> Joe said, the IPs are always changing.
Does anyone know if they are reasonably static in an Express Route scenario?
Mark.
I think the difficulty lies in appropriately marking the traffic. Like Joe
said, the IPs are always changing.
On Tue, Jul 9, 2019, 9:15 AM Mark Tinka wrote:
>
>
> On 9/Jul/19 16:08, Joe Yabuki wrote:
> > Hi all,
> >
> > Thanks for your replies,
> >
> > I'll rephrase just to clarify, our aim is
On Tue, 9 Jul 2019 at 17:05, Tom Beecher wrote:
> Generally speaking, I agree that making QoS features work consistently on an
> external network you do not control is a fool's errand.
>
> But if that language was inserted into the contracts, and you can
> demonstrably prove it's not being
On 9/Jul/19 16:08, Joe Yabuki wrote:
> Hi all,
>
> Thanks for your replies,
>
> I'll rephrase just to clarify, our aim is to do QoS within our
> extended LAN (From remote sites to the Datacenter using the MPLS
> provider as transit) - and we can't use DIA for a security reasons...
>
> So
On 9/Jul/19 16:01, Tom Beecher wrote:
>
>
> But if that language was inserted into the contracts, and you can
> demonstrably prove it's not being done, enforcing contract terms
> should always be done. Depending on the strength of the remedy, could
> have been a lot of free service, enough
>
> At a previous employer (AOL, doing VoIP for customer service / call
> centers, ~2004) we had a number of contractual agreements with
> multiple providers to honor our QoS markings -- as far as I could tell
> (marking test traffic under congestion events) only one of about seven
> did anything
95% sure that Google Fiber only sells access, not point to point or wave
services.
On Tue, Jul 9, 2019 at 9:30 AM Robert DeVita wrote:
> Does anyone have a sales contact at Google Fiber, looking for Dark fiber
> in Pflugerville, TX back to Datafoundry TX1
>
>
>
> Thanks
>
>
>
> Rob
>
>
>
>
Does anyone have a sales contact at Google Fiber, looking for Dark fiber in
Pflugerville, TX back to Datafoundry TX1
Thanks
Rob
[photo]
[https://s3.amazonaws.com/images.wisestamp.com/symbols/frames/frame_bubble_left_top_part.png]
Robert DeVita
Managing Director, Mejeticks
To quote from that URL:
QoS only works as expected when implemented on all links between
callers. If you use QoS
on an internal network and a user signs in from a remote location,
you can only prioritize within
your internal, managed network.
Mark.
On 9/Jul/19 02:41, cyrus ramirez
On 9/Jul/19 01:00, Keith Medcalf wrote:
> Using Orifice 342 will hurt you.
Can't choose what my customers like :-).
Mark.
On Mon, Jul 8, 2019, at 18:15, Joe Yabuki wrote:
> Hi all,
>
> How do you deal with QoS for Office365, since the IPs are subject to changes ?
For "Classic QoS" : you don't. At best you tell the customer it's done without
actually doing anything (it very often works). If it doesn't, see
39 matches
Mail list logo