Tony Hain wrote:
> Steve Blake wrote:
>
> > I agree with your conclusion, but I disagree with the assumptions
> > you are making about diffserv (for the sake of argument, say).
> I assume you are talking about the WG not the protocol. :)
Actually, the opposite. :)
> > RFC2475 was built on the assumption of bilateral agreements between
> > peering providers, because that was the only model that had a hope
> > of being deployed.
> But bi-lat's don't necessarily require mutability of the TC field. That
> was simply a concession to those who wanted knobs to make it more
> difficult for the less skilled. Now we have a mechanism that only has
> a hope of being deployed, but is operationally useless on a global
> scale because it lacks any context.
Diffserv on a global scale is useless, in the sense that, I don't care
what QoS you want for your packet unless you are paying me directly,
or paying me via a proxy that I peer with, ad infinitum.
> > The Diffserv flow-label proposal is trying to
> > invent an end-to-end, in-band QoS "signaling" mechanism to operate in
> > parallel with the hop-by-hop DSCP "signaling".
> Basically the hop-by-hop decisions have to be based on consistent
> end-to-end semantics of a set of bits, but the TC field was allowed
> to be randomized so it is currently useless for that purpose. This
> is still fixable by locking down the PHBs and matching DSCPs, so
> there is no need for taking additional header bits.
There is no need to take additional header bits period, in my view,
irrespective of whether the hop-by-hop semantics of the DSCP are changed.
Diffserv does support some "flexibility" that in retrospect is more silly
than useful, IMHO, but even if the mapping of DHCP-to-PHB were fixed,
the PHBs have been defined in such a way that they have no obvious
relationship to a particular user's or application's QoS preferences, and
even if that were not the case, the DSCP still remains mutable, because a
network has to be able to protect it resources from upstream freeloaders.
> > The only additional
> > in-band information that would be remotely useful for Diffserv would
> > be a credit card account number.
> Not if the proposed new end-to-end signaling is left as mutable. There
> will be a never-ending series of requests for bits until it is accepted
> that what is required is an end-to-end immutable set that the origin
> node uses to identify its intent for the packets, (in or out of band).
> The intervening networks will always make local decisions based on
> those bits, so there is no need to rewrite them at every domain boundary.
> All the TC field is used for now is an embedded MPLS type tag, so why is
> it embedded? Shouldn't it be the end-to-end consistent set of bits and
> let MPLS do the tagging it will undoubtedly do for TE purposes anyway?
As I said, the only useful immutable information is a billing account
number. That could be propagated via signaling (Intserv), although that
does not appear to be a popular option these days. There is no way we will
ever try to shoehorn that kind of information in-band into packets.
The Diffserv model is to aggregate classification information at domain
boundaries, so that the billing model will scale. The DSCP is the field
that conveys this information between boundaries. It must remain mutable
to protect from freeloaders (as an alternative to simply discarding their
packets). I haven't seen any evidence that six bits isn't adequate for
this purpose.
We cannot rely on MPLS labeling because MPLS isn't pervasive (yet).
The argument that Diffserv critically depends on the ability of a
router to classify the application type in the middle of the network is
incorrect; the Diffserv model will work if this function is restricted
to the edges of the network, and then only because of the lack of
infrastructure which would allow the source host to mark the DSCP
meaningfully.
I would personally prefer that the flow label would remain an end-to-end
immutable field that uniquely identifies flows originated by a particular
source node, though as a forwarding engine designer, it doesn't matter;
we will find the bits we need to find regardless.
Regards,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake <[EMAIL PROTECTED]>
Ericsson IP Infrastructure 919-472-9913
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
