Francis Dupont wrote:
>
> In your previous mail you wrote:
>
> > Alex, perhaps I was unfair about the c) option.
>
> You were Francis.
>
> => I agree, c) is not a bad idea, the problem is with diffserv itself
> (the MF re-classification on the 5/6 tuple or worse which:
I do not agree that there is a problem with Diffserv itself or with M-F
classifiers.
> [..]
> Core transit ISPs
> are pseudo-randomly (for us) chosen and if they re-classify my packets
> I'd like to know what silly rules on the 5/6 tuple they use...
No silly rules, just rules. I would like to know too, and I may learn
the standard rules but the proprietary rules, is much more difficult.
Practically though, for most people, it would not really matter, as long
as core providers provide the service people or people's access
providers
pay for (on people's behalf).
> [...]
>
> Since, with IP QoS, the QoS information is in the same class, relative
> to privacy,
> with the forwarding information, if one needs to apply full privacy to
> QoS information,
> it will apply the same criteria as for forwarding information: use
> tunnel ESP.
>
> => I disagree: your proposal is to drop diffserv QoS if I'd like to get
> security/privacy. I can't accept this.
You do not have to drop diffserv QoS.
Let's acknowledge first, that what is the most important is the
confidentiality of the application payload, i.e. the user's message.
Hiding completely the fields of the transport header, or the fields of
the IP headers, that one may be worried about, does not eliminate the
use of forwarding and QoS information.
The tunnel header carries forwarding and QoS information that is
pertinent to the tunnel
(traffic). If the tunnel carries one flow, then that applies to one
flow. If it carries an aggregation of flows, it applies to that set of
flows.
> As intserv has not this issue,
> the problem seems to be in the QoS information, and how it can be used
> by ISPs.
By the way, RFC 2207 applies only to non-flow label based Intserv. So
your assertion is not true for the use of Intserv flow label.
Your 'has not this issue', or that the mechanism is perfect, applies in
general terms. In very specific terms, for instance, it is not clear to
me how an RFC 2207 classifier is able to distinguish one user's
micro-flows between two end-nodes, based on 4-tuple classification rule.
> I have contracts with my first ISPs (and my correspondent with last ISPs)
> so I can mark my packets with the desired QoS, ISPs will apply the QoS
> (keep my packets, drop others :-) and send the bill to me.
For this case, if the providers have networks in which they use only
Diffserv, why not allow them to use the flow label with Diffserv?
> So I propose to refocus the discussion on the real issue: what will be
> in practice MF re-classifiers and what constraints will this imply?
>
> Francis
Let's not go on that path. We go in circles, and move the focus, when in
fact
the problem is fundamentally very simple:
1. premises
a. Intserv and Diffserv are two IP QoS models.
b. Intserv classifiers are similar to Diffserv M-F classifiers
(in fact in hardware, one can use the same engine)
c. the IPv6 flow label has a QoS purpose
d. the IPv6 flow label can be used with Intserv
RFC 2207 states reason - more efficient access to header fields
2. conclusion
a. Diffserv should be able to use the IPv6 flow label, like
Intserv.
based on same reasons - more efficient access to header fields.
Regards,
alex
S/MIME Cryptographic Signature
