Francis Dupont wrote: > > > 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. This is your interpretation. This is needed wherever there is a Diffserv router which does M-F classification, whether access or edge. > 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. What the PHB ID flow label does is irrelevant, relative to the ability to do an efficient M-F classification, using the same fast and efficient classification engine as the one that can be used by Intserv. This ability is what is relevant. > 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. > As the resetting of a machinery to a fresh starting point, anywhere in the network, the M-F re-classification can be seen in fact, as part of the mechanisms that helps Diffserv scale. > > 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. > It is not a problem at all. It is a feature -- please see above. > 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. Dynamic or static is irrelevant to the control plane. Classification rules have to be set in a classification rules table, whether for a short duration, or long duration. In fact noone requires a Intserv flow state to be shorter than a certain time interval, so it can be as long as a week, or a month. It is irrelevant to the data plane classification engine that processes the packets, since they process packets regardless of how long a certain classification rule table entry is lived. > > 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. This has no relevance on the data plane classification engine - see above. The statically defined aggregates can have a fine granularity of one application communication between two end nodes. > > 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. I always assumed that the Diffserv flow label based MF classifier, will not exclude the possibility of a 1-1 mapping between a slow classifier ( 5-tuple) and a fast flow classifier (3-tuple). In fact that is one of the essential reasons for the proposals. > 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] I agree with completely, but since you brought it up, I responded. Regards, Alex
smime.p7s
Description: S/MIME Cryptographic Signature
