In your previous mail you wrote:
> 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.
=> I've done an assumption on the default rule (not known ports), you too.
If the default is not the worse QoS then to avoid to get the worse QoS
is too easy, I could already see that with the port 80 -> low priority
rule someone tried to apply here.
> 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?
=> they don't need this. The PHB ID flow label extends a bit the range
of validity of marks I've put on my packets but they don't change something
for core transit ISPs. This is a partial improvement, a real fix needs
to fix the status of MF re-classification over the 5/6 tuple or worse
in the middle of the network.
> 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?
Let's not go on that path.
=> I disagree: this is the real problem.
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)
=> I disagree with 1b, Intserv classifiers are dynamic and they don't need
to be over the 5 tuple because of 1d.
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.
=> I disagree: Intserv works on dynamically defined micro-flows,
Diffserv works on statically defined aggregates.
based on same reasons - more efficient access to header fields.
=> if you'd like to apply this argument you have to remove the possibility
to apply a MF classifier over the 5/6 tuple anywhere. Intserv does this
by 1b because signaling provides a 1-1 mapping between a slow MF classifier
over the 5 tuple and a fast MF classifier over addresses+flow label.
You can't do that with Intserv just because you don't know what are
the silly rules applied in the middle of the network: a priori you don't
know the characterization of aggregates so I can't see you can map them
to flow labels.
So IMHO the issue is really MF re-classifiers in core transit ISPs
(something which is not an IPv6 WG mailing list topic :-).
Regards
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
