All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kalle Valo <kalle.valo@iki.fi>
To: Dunc <dunc@lemonia.org>
Cc: David Miller <davem@davemloft.net>,
	kaber@trash.net, netdev@vger.kernel.org,
	linux-wireless@vger.kernel.org
Subject: Re: Network QoS support in applications
Date: Tue, 26 Jan 2010 16:27:29 +0200	[thread overview]
Message-ID: <87iqaplz5a.fsf@purkki.valot.fi> (raw)
In-Reply-To: <4B5EF5DF.2070005@lemonia.org> (dunc@lemonia.org's message of "Tue\, 26 Jan 2010 14\:02\:07 +0000")

Dunc <dunc@lemonia.org> writes:

> If applications set the QoS values, the who's to stop someone (for
> example) writing a bittorrent client that marks all packets for the
> highest priority as if they were VoIP or something?

Nobody. That would a bug in the application which should be fixed.
Badly behaving applications can disrupt the network, with or without
QoS support. So no need to blame QoS for this.

And if the network doesn't want to trust applications, it's free to do
so. Nothing prevents that. And based on the discussion so far, the
networks already ignore QoS classifations coming from other network
realms.

> At this point all the good work done in the applications is useless
> and the network admin is going to have to not trust the QoS values
> and then attempt to classify traffic by themselves, so it was all a
> waste of time.

Because of one badly behaving application? I think that's a bit
extreme. If QoS API brings benefits to the user (for example in this
case bittorrent giving bandwith to more important streams), most
probably applications try to get it right.

> It's probably better to just always leave it up to the network devices IMHO.

If we are happy with the current situation, sure, no need to do
anything. But if we want to improve network services, we need to start
to do something about this.

I want to emphasise that we shouldn't look at this just from the core
network point of view, but with a broader look. We have now different
network technologies and devices where Linux is used. We should not
just look at this from a point where a Linux workstation (or router)
is connected with a fast access to Internet. For example, I want to
have my ssh terminal connection higher priority compared to emails
downloading background on a slow cellular network.

-- 
Kalle Valo

WARNING: multiple messages have this Message-ID (diff)
From: Kalle Valo <kalle.valo-X3B1VOXEql0@public.gmane.org>
To: Dunc <dunc-9b9L1Hpe0sBAfugRpC6u6w@public.gmane.org>
Cc: David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>,
	kaber-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org,
	netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: Network QoS support in applications
Date: Tue, 26 Jan 2010 16:27:29 +0200	[thread overview]
Message-ID: <87iqaplz5a.fsf@purkki.valot.fi> (raw)
In-Reply-To: <4B5EF5DF.2070005-9b9L1Hpe0sBAfugRpC6u6w@public.gmane.org> (dunc-9b9L1Hpe0sBAfugRpC6u6w@public.gmane.org's message of "Tue\, 26 Jan 2010 14\:02\:07 +0000")

Dunc <dunc-9b9L1Hpe0sBAfugRpC6u6w@public.gmane.org> writes:

> If applications set the QoS values, the who's to stop someone (for
> example) writing a bittorrent client that marks all packets for the
> highest priority as if they were VoIP or something?

Nobody. That would a bug in the application which should be fixed.
Badly behaving applications can disrupt the network, with or without
QoS support. So no need to blame QoS for this.

And if the network doesn't want to trust applications, it's free to do
so. Nothing prevents that. And based on the discussion so far, the
networks already ignore QoS classifations coming from other network
realms.

> At this point all the good work done in the applications is useless
> and the network admin is going to have to not trust the QoS values
> and then attempt to classify traffic by themselves, so it was all a
> waste of time.

Because of one badly behaving application? I think that's a bit
extreme. If QoS API brings benefits to the user (for example in this
case bittorrent giving bandwith to more important streams), most
probably applications try to get it right.

> It's probably better to just always leave it up to the network devices IMHO.

If we are happy with the current situation, sure, no need to do
anything. But if we want to improve network services, we need to start
to do something about this.

I want to emphasise that we shouldn't look at this just from the core
network point of view, but with a broader look. We have now different
network technologies and devices where Linux is used. We should not
just look at this from a point where a Linux workstation (or router)
is connected with a fast access to Internet. For example, I want to
have my ssh terminal connection higher priority compared to emails
downloading background on a slow cellular network.

-- 
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2010-01-26 14:27 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-26  8:27 Network QoS support in applications Kalle Valo
2010-01-26  8:27 ` Kalle Valo
2010-01-26 11:30 ` Patrick McHardy
2010-01-26 11:30   ` Patrick McHardy
2010-01-26 11:51   ` Kalle Valo
2010-01-26 11:51     ` Kalle Valo
2010-01-26 11:59     ` Patrick McHardy
2010-01-26 11:59       ` Patrick McHardy
2010-01-26 12:16     ` David Miller
2010-01-26 12:16       ` David Miller
2010-01-26 12:56       ` Kalle Valo
2010-01-26 13:06         ` David Miller
2010-01-26 13:47           ` Kalle Valo
2010-01-26 13:47             ` Kalle Valo
2010-01-26 14:02             ` Dunc
2010-01-26 14:27               ` Kalle Valo [this message]
2010-01-26 14:27                 ` Kalle Valo
2010-01-26 21:54                 ` Edgar E. Iglesias
2010-01-26 21:54                   ` Edgar E. Iglesias
2010-01-27  7:11                   ` Kalle Valo
2010-01-27  1:57               ` Zhu Yi
2010-01-27 13:24               ` Benny Amorsen
2010-03-11 19:21               ` Philip A. Prindeville
2010-03-11 19:27                 ` David Miller
2010-03-11 19:27                   ` David Miller
2010-03-11 19:29                   ` Philip A. Prindeville
2010-03-11 19:29                     ` Philip A. Prindeville
2010-05-19  0:04                     ` Philip A. Prindeville
2010-05-31 19:30                       ` Ben Gardiner
2010-05-31 19:30                         ` Ben Gardiner
2010-05-31 20:28                         ` Philip Prindeville
2010-01-26 14:43             ` Rémi Denis-Courmont
2010-01-26 14:43               ` Rémi Denis-Courmont
2010-01-26 13:06         ` Henning Rogge
2010-01-26 13:06           ` Henning Rogge
2010-01-27  6:59           ` Kalle Valo
2010-01-26 15:29       ` Steven Blake
2010-01-27  7:03         ` Kalle Valo
2010-01-27 16:18 ` Olaf van der Spek
2010-01-27 16:26   ` Greg Oliver
2010-03-11 18:56 ` Philip A. Prindeville

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87iqaplz5a.fsf@purkki.valot.fi \
    --to=kalle.valo@iki.fi \
    --cc=davem@davemloft.net \
    --cc=dunc@lemonia.org \
    --cc=kaber@trash.net \
    --cc=linux-wireless@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.