See comment at the end.
Steve Blake wrote:
>
> Brian Carpenter wrote:
>
> > > Therefore it is pointless adding any semantics to the field, because
> > > even if there, they can't (won't) be used.
> >
> > But there's a recursion here. If you choose to believe port and protocol
> > numbers, then all cheaters have to do is encapsulate their low priority
> > packets in what look like VoIP packets and they will get real time
> > performance. So whatever you choose to believe (except the destination
> > address) could be bogus.
> >
> > It turns out this doesn't matter. If somebody cheats in this way, they will
> > pay the tariff for better QoS anyway - so why would the ISP care? I think
> > that is the rebuttal to Steve Blake's argument - customers pay for the service they
> > actually get, even if they are disguising their traffic. So sure they can cheat,
> > but they are the losers.
>
> To summarize: the customer will pay for higher CoS, and can either explicitly
> "signal" the provider of the desired per-packet CoS (via the traffic class
> or flow label fields), or let the provider infer the required per-packet CoS,
> according to agreement, by looking at the protocol/ports and addresses.
>
> Pushing protocol/port filtering to the provider is easier to deploy if I
> trust the hosts in my network: I don't have to change the hosts or deploy
> any Diffserv filtering/marking in my firewall. If I trust the hosts to
> put legitimate values in the flow label field, then I can just as easilly
> trust them to put legitimate values in the traffic class field. If I
> don't trust my hosts, then I need to enforce my Diffserv policy at the
> firewall anyway.
>
> So I think the argument boils down to whether 6 bits or 20 bits is enough
> to convey application CoS preferences to the network.
Excellent summary. We originally chose a 6 bit diffserv field partly because
it was available in both IPv4 and IPv6, and partly because it allows for
very efficient classification in *core* routers, with the more demanding
multi-field classification being left to border routers.
The question before the house (in the end that means both ipng and diffserv)
is whether the added complexity of adding the flow label to the diffserv
model is justified by the gain in expressiveness. It doesn't do anything
for the trust model.
Brian
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
