There seem to be two separate things going on here, and they appear to
be getting mixed.
The first thing is the notion that the host should set a non-zeero value
into the flow label. They should do so with the constraint that
different packets which are part of the same flow MUST have the same
flow label. And flows which the end host is willing to have treated
(even if treated may mean simply in terms of which link in a LAG or ECMP
selection is used) differently may have different flow labels.
However, a network can not give QoS treatment purely on the basis of
source and dest IPv6 address plus flow label. There simply is not
enough information. A client provided flow label is not a DSCP code point.
So networks that want to do QoS will have to do something additional.
What? That depends upon what they want to do. I would hope that
whatever they do it does not destroy the granularity of the flow label
as described above.
If we can count on hosts setting the flow label with suitable
granularity, then we can use the flow label (plus src and dest IPv6
address) in our ECMP and LAG hashes without having to look for protocol
and port numbers. That avoids much complexity related to next headers
and similar problems. And it is not subject to an attack by someone
mis-setting the flow label field.
The one obvious conclusion here is that if we want hosts to actually set
flow labels, then we are largely preempting network modification of
those flow labels. Whatever setting we want to allow, it would have to
preserve the granularity of the original flow label variation. Which is
pretty hard.
Now, I personally don't quite understand what the "modified flow label"
proposal is for. As such, I don't mind giving it up. Particularly if I
get cleaner packet processing for the normal case as a result.
Yours,
Joel
Mohacsi Janos wrote:
On Thu, 15 Apr 2010, Simon Perreault wrote:
On 2010-04-15 10:38, Mohacsi Janos wrote:
Why cope with QoS if somebody is sending packets to black-hole?
I don't understand your question, but here's an example use case of
the attack I'm suggesting:
I want to evade an SFQ QoS for a single flow. If the QoS is based on
the flow field, I can just put random values in the flow field so that
my packets appear to come from multiple flows, which will let me get
better throughput.
Then we are speaking two different beasts:
- you are speaking about a policed and/or rate limited flows
- I was speaking about a preferential treatment of sent flows
Many other examples come to mind...
This usage of the flow field would need to be treated just like the
DSCP field. Maybe you can use it in some applications, not in others.
But a recommendation that all hosts on the Internet set it would be
pointless if intermediate networks can't or won't use it.
That is why we are thinking of different models:
Diffserv like architecture for flow field.
Do we need more classes in a backbone than available in the current
DSCP/diffserv model?
In the diffserv model you are rewriting DSCP values at the
administrative domains. Do we want to rewrite flow fields similarly? or
is it e2e?
Also you mark/remark packets in you aggregation network according to the
services and origin. Do we want to change flow filed?
Flow field is a tool for network operators to better classification or
more e2e tool for applications?
Simon
--
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server --> http://numb.viagenie.ca
vCard 4.0 --> http://www.vcarddav.org
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
