Tony Hain wrote:
>
> Keith Knightson wrote:
>
> > Or is this a stupid suggestion?
>
> There are no stupid questions. Some of the pushback is
> simply based on the fact that the diffserv model of QoS
> is inherently broken because there is no end-to-end
> immutable set of bits for local decisions to be based on.
This is a very unfair comment. Diffserv is just fine in the
case of unencrypted traffic. It has a problem (and so does
intserv I suspect) with tunnel or transport mode ESP.
> What we have on the table is a proposal to take over
> part of another field to create that set of bits, but
> even that contains the argument that the bits should be
> mutable.
No it doesn't. They should be set at source. (But anyway, why
would it matter if they are mutable, since they aren't covered
by checksum? I'm not aware of a law of nature against mutable bits.)
> As soon as that is deployed and proven
> inadequate they will be back for another set of bits.
There would indeed be the option of defining an IPv6 header
not covered by ESP for this. But I think that would raise traffic
analysis issues way beyond those raised by the current proposal.
Anyway, in this last sentence you have stopped arguing on the
merits.
> The diffserv WG should have defined a set of PHBs with
> global context and mapped a set of DSCPs to those. It
> chose not to,
No, that is in fact what we did, but at the specific insistence
of the ISPs active in the design of diffserv, we made all of
the mappings SHOULD instead of MUST. You want to ding the WG
for meeting a clearly stated key requirement of the principal
customer set?
> and now to make products work people are
> looking for another set of bits.
er, try "to give IPv6 an advantage over IPv4 in the case of
encrypted traffic with a QOS requirement..." Products work just fine
the way things are.
> That is the wrong
> process. The diffserv WG should go back and fix the
> immutability problem they created.
Immutablity isn't the problem. Encryption of the port and protocol
numbers is the problem. I could equally well say that IPSEC should
go back and fix the invisibility problem they created. What I am actually
saying is that this WG should go back and fix the ambiguity problem
created by the Appendix to RFC 2460.
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]
--------------------------------------------------------------------
