I am not sure how well commercial devices implement QoS. As you saw it is
very powerful.
On Wed, Nov 29, 2017 at 2:30 PM, Eric Oyen <
eric.oyen@icloud.com> wrote:
> I was trying to optimize throughput to the chrome cast device (video
> streaming). basically, I was trying to dedicate 6 Mbits/sec for IPTV. ran
> into a couple of issues and will have to do further reading on the Asus
> router I am using.
>
> -eric
> from the central office of the technomage Guild, Network troubleshooting
> div.
>
> On Nov 29, 2017, at 2:00 PM, Herminio Hernandez, Jr. wrote:
>
> What exactly were you doing? What NOS were you applying the policies? QoS
> is an entire suite of tools used for traffic management. It can be as light
> or heavy as you want it to be.
>
> On Wed, Nov 29, 2017 at 1:52 PM, Eric Oyen <eric.oyen@icloud.com> wrote:
>
>> I have actually done performance testing with qoS here. believe me, it
>> does affect other users on my circuit. sure, it can be useful, but it's a
>> sledge hammer where a light touch is required.
>>
>> -eric
>> from the central offices of the Technomage Guild, Network Ops Center
>>
>> On Nov 29, 2017, at 10:07 AM, Carruth, Rusty wrote:
>>
>> I strongly disagree with the statement “which the internet needs to
>> function”.
>>
>> No, the internet does NOT need QoS in order to function. Its been
>> working fine for years without that. Its just people trying to do things
>> on the internet that it was not designed for who demand QoS in order to
>> co-opt the internet for THEIR use.
>>
>> If you insist that the internet MUST have QoS to function, then that’s
>> the end of the discussion. Those who believe that must demand NO NN,
>> otherwise the internet won’t work the way they think it should. Those who
>> have not bought in to that assumption may be on either side of the debate.
>> But if you buy the theory that QoS is required for the internet to function
>> then you must oppose anything that allows the internet to function the way
>> it was designed.
>>
>> And the point about QoS effectively stealing bandwidth from other users
>> is something we’ve not spoken of thus far, as far as I can remember. But
>> it is something to keep in mind – hacking the medium to enable realtime
>> data reduces the usability of the internet for all people who are not using
>> realtime data.
>>
>> Which brings up a rabbit trail which I’ll start a new thread upon.
>>
>> Rusty
>>
>> *From:* PLUG-discuss [mailto:plug-discuss-bounces@lists.phxlinux.org] *On
>> Behalf Of *Herminio Hernandez, Jr.
>> *Sent:* Tuesday, November 28, 2017 3:33 PM
>> *To:* Main PLUG discussion list
>> *Subject:* Re: new thread: QoS, latency, bandwidth and the FCC/net
>> neutrality debate
>>
>> Here is a good definition of QoS from Cisco: "The ability of the network
>> to provide better or 'special' service to a set of users/applications to
>> the detriment of other users/application". Net Neutrality cannot exist in a
>> network where QoS is needed which the internet needs to function.
>>
>> On Tue, Nov 28, 2017 at 5:15 PM, Herminio Hernandez, Jr. <
>> herminio.hernandezjr@gmail.com> wrote:
>> I understand your frustration, but to be frank it is unrealistic to think
>> that the industry is going to redesign the physical infrastructure to
>> accommodate voice and video. The ship has sailed there. Converged
>> infrastructure is here to stay. Now the job is to find the best solution
>> for this reality and Net Neutrality is not it IMO.
>>
>> On Tue, Nov 28, 2017 at 5:05 PM, Carruth, Rusty <Rusty.Carruth@smartm.com>
>> wrote:
>> I’m going to have to switch to inline answers. See below.
>>
>>
>>
>> *From:* PLUG-discuss [mailto:plug-discuss-bounces@lists.phxlinux.org] *On
>> Behalf Of *Herminio Hernandez, Jr.
>> >TCP would not solve the issue. Think about constantly having to ask the
>> person on the other end of a phone conversation to repeat themselves
>> because the sound kept dropping. That would drive you be insane. That is
>> very much like TCP. >Voice and Video traffic simply will not work in
>> that scenario.
>>
>> Which is pretty much to my point. TCP doesn’t work well for realtime
>> data (unless perhaps you have nobody else on the wire and a perfect wire).
>>
>> So, the first attempt at a workaround was to use UDP, whose performance
>> fits better with ‘almost realtime’ data in a network that was fairly
>> quiet. When that began to fail because of busy networks, something else
>> was needed.
>>
>> The next attempt seems to be to change the network transport protocol to
>> prioritize certain packets over other packets, which is IMHO risky business.
>>
>> IF, and ONLY IF, there is absolutely no allowance for a transporter of
>> packets to give (or remove) special priority to certain packets based upon
>> something other than their type (VoIP, video), then the issue of realtime
>> data on the interent MIGHT have found a way out of the problem of trying to
>> force something onto a medium which it wasn’t designed to handle. But I
>> still feel this is trying to force a design onto something that can’t
>> handle it.
>>
>> In any case, I still think that those who use ‘the internet’ for realtime
>> data and wish to force it to do what it was never designed for have MUCH
>> more of a requirement to ‘play nice’ than those who use it for what it was
>> originally designed.
>>
>> > You are right ethernet was not designed for voice and video in mind,
>> but that is where we are at and it is not changing.
>>
>> So then you should reject any attempt to cram a bad design onto something
>> that wasn’t designed for it. Which those against any sort of net
>> neutrality seem to be trying to do – force a bad design on the wrong medium
>> (assuming I have half a clue as to what NN is SUPPOSED to be).
>>
>> Those who wish to transport realtime data over a network should design a
>> network that can do that, not co-opt somebody else’s network. Again, IMHO.
>>
>> Rusty
>>
>> > On Tue, Nov 28, 2017 at 4:37 PM, Carruth, Rusty <
>> Rusty.Carruth@smartm.com> wrote:
>> I still disagree.
>>
>> First, if they needed reliable delivery of packets, then they should use
>> TCP.
>>
>> My understanding of the ‘theory’ of why streaming services use UDP is
>> that it doesn’t hurt ‘much’ if you lose a ‘few’ packets – not as much as
>> them showing up in the wrong order, or massively delayed, so using UDP is a
>> workaround to try to use a medium that wasn’t actually designed to carry
>> realtime data.
>>
>> So, I go with the line of reasoning that claims that using ‘the internet’
>> for real-time data is to misuse the medium. And if a medium is misused,
>> those so misusing it shouldn’t be surprised if it doesn’t work in a way it
>> wasn’t designed to do.
>>
>> Yes, it doesn’t work well with real-time data.
>>
>> Wasn’t intended to, IMHO.
>>
>>
>> (Just a grumpy old man who knows that the internet pre-existed the guy
>> who claims to have invented it… And who even knows what ftp, telnet, rcp,
>> gopher, and uucp used to mean ;-) (and who performed tests to prove that,
>> between two Solaris boxes on a COAX ‘ethernet’ cable, FTP was faster than
>> anything else. But I digress! ;-)
>>
>> *From:* PLUG-discuss [mailto:plug-discuss-bounces@lists.phxlinux.org] *On
>> Behalf Of *Herminio Hernandez, Jr.
>> *Sent:* Tuesday, November 28, 2017 2:28 PM
>>
>> *To:* Main PLUG discussion list
>> *Subject:* Re: new thread: QoS, latency, bandwidth and the FCC/net
>> neutrality debate
>>
>> Rusty,
>>
>> I know my language was strong but let explain why, First not all traffic
>> behaves the same. Go back to my initial post on the differences between TCP
>> and UDP. UDP by the nature of the protocol is more sensitive to things like
>> packet loss, latency, etc. So in order to deliver UDP services reliably (ie
>> most streaming services) some type of prioritization must occur. If not
>> then video will be constantly buffering and VoIP calls will drop. The
>> reason why there exist QoS policies is because engineers are try to work
>> with the transport medium we have. Bandwidth is a limited resource and you
>> have all these different types of traffic contending for the same resource.
>> If people expect web browsing, YouTube, Mumble, Netflix, SFTP, all run
>> efficiently across the wire then prioritization is a reality that will not
>> go away. This is nature of modern networks where data, voice and video are
>> all converged on the same media. The reason I used the language I did was
>> b/c an engineer who does not understands this and actually thinks that 'all
>> traffic' can be treated the same will actually bring harm to the network.
>> He will be doing a great disservice to users he supporting all under the
>> false notion of 'equality'.
>>
>> On Tue, Nov 28, 2017 at 2:38 PM, Carruth, Rusty <Rusty.Carruth@smartm.com>
>> wrote:
>> Yes, lets get back to the technical issues.
>>
>> First, though let me review: Apparently an ISP has been targeting certain
>> SITES or DOMAINS and throttling them. If that the case, then a discussion
>> of the network issues is beside the point - the issue of treating certain
>> endpoints differently based upon some non-technical issue would be the
>> issue.
>>
>> Anyway, that being said -
>>
>> I was actually somewhat offended when the statement was made claiming
>> that anyone who believes that all traffic, regardless of type (voice, file,
>> web pages, etc) should be treated the same was an idiot.
>>
>> On what basis is someone who thinks that a certain type of traffic
>> DESERVES a different assurance of throughput against any OTHER type of
>> traffic? If the entity using a certain transport mechanism has different
>> requirements than the transport medium can provide, then they are the
>> unwise ones. And have no right to demand that the transport medium change
>> to accommodate their demands.
>>
>> Especially at everyone else's expense.
>>
>> Why does VoIP or Video REQUIRE special treatment? I claim that either
>> the systems which use these technologies either figure out ways to work
>> within the limitations of the medium, or find a different medium. Don’t
>> demand that the medium ADD special treatment for you.
>>
>> One might then say that having the user pay extra for the special
>> treatment would address this, and not force the cost of this on to all
>> users, but this opens the door for a medium provider to use their
>> (essentially) monopoly position to materially affect the open market in
>> ways which could easily damage the open market.
>>
>>
>> (I was tempted to say something about 'in the beginning, all traffic was
>> just packets - and they still are just packets'. ;-)
>>
>> All the above has NOTHING WHATSOEVER to do with the company I work for,
>> its IMHO.
>>
>>
>> -----Original Message-----
>> From: PLUG-discuss [mailto:plug-discuss-bounces@lists.phxlinux.org] On
>> Behalf Of Herminio Hernandez Jr.
>> Sent: Tuesday, November 28, 2017 7:44 AM
>> To: Main PLUG discussion list
>> Subject: Re: new thread: QoS, latency, bandwidth and the FCC/net
>> neutrality debate
>>
>> I do not what you are getting at? Yes we all look at Net Neutrality
>> through the lens of our assumptions on how the economy should be built. I
>> am sure many would believe that government should a significant role is
>> managing and others not. Most of this thread has focused on that.
>>
>> I would love to discuss more the technical side of the debate. The first
>> part of original post thread were the technical reasons why I felt NN was
>> bad policy.
>>
>> Sent from my iPhone
>>
>> > On Nov 28, 2017, at 7:24 AM, Steve Litt <slitt@troubleshooters.com>
>> wrote:
>> >
>> > On Mon, 27 Nov 2017 22:52:04 -0700
>> > "Herminio Hernandez Jr. " <herminio.hernandezjr@gmail.com> wrote:
>> >
>> >> First since I do not believe in
>> >
>> >> central planning
>> > ^^^^^^^^^^^^^^^^
>> >
>> >> I do not know what
>> >> competitors will once they have the freedom to offer services. This
>> >> what is awesome about the
>> >
>> >
>> >> Free Market,
>> > ^^^^^^^^^^^
>> >
>> >> if there is market that was
>> >> moved closed off now open they will find creative ways to provide
>> >> services.
>> >
>> > Looks to me like Net Neutrality is being used as a proxy for some
>> > much more generic theories.
>> >
>> > SteveT
>> >
>> > Steve Litt
>> > November 2017 featured book: Troubleshooting: Just the Facts
>> > http://www.troubleshooters.com/tjust
>> > ---------------------------------------------------
>> > PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
>> > To subscribe, unsubscribe, or to change your mail settings:
>> > http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>
>>
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>
>>
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>
>>
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>
>>
>>
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>
>
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.phxlinux.org
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.phxlinux.org/mailman/listinfo/plug-discuss
>
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.phxlinux.org
To subscribe, unsubscribe, or to change your mail settings:
http://lists.phxlinux.org/mailman/listinfo/plug-discuss
(text/plain)