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 > 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 >> 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 >> wrote: >> > >> > On Mon, 27 Nov 2017 22:52:04 -0700 >> > "Herminio Hernandez Jr. " 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 >> > >