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