Just some comments for clarifying some stuff that keeps coming up
repeatedly:
Brian E Carpenter wrote:
>
> 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.
>
IPv4 intserv shares the same difficulty of doing MF-classification with ESP.
However, in IPv6 the flow label can be used in MF-classification for intserv
semantics, even when ESP is used.
> > 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.)
>
For the proposed diffserv usage the flow label should be mutable to enable
policing and aggregation. The point is that the flow label should NOT be
locally mappable, it MUST always contain a standardized value, or it's
semantics must be signaled (�la intserv).
> > 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?
>
It may be that diffserv cannot be changed NOT to allow local mapping any
more, but where are these ISPs NOW?
> 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.
As I said above, it seem to me that any diffserv usage would need
mutability. Encryption is NOT the problem either. The problem is the local
mappability of the DSCP field. Amending the flow label field to include very
"broad definitions for flows" (indeed, behavior aggregated flows) can be a
plausible remedy to this problem. (No harm unless we conclude that 19 bits
is not enough for host-to-host specific flows.)
The IPsec invisibility *feature* is by design.
Another problem is the MF-classification defined by the diffserv: How long
you think it takes for the SLAs to be updated end-to-end (or more precisely,
hop-by-hop), when two consenting hosts switch to SCTP instead of TCP? No
such problem with intserv, since the signaling carried out before the
session using SCTP would have it's MF-classifier say 'SCTP' instead of 'TCP'
(or better yet, specify the MF-classifier in terms of flow label and IP
addresses only).
Possibly the same problem when changing from IPv4 to IPv6 (if MF-classifiers
in the diffserv ingress specify address (prefixes)).
I hope that if we'll have the flow label support for what Brian is asking
(standard, non-mappable behavior aggregates), he'll promise to remove the
MF-classifiers peeking into transport headers from the diffserv specs :-)
(also from the non-ESP case).
> What I am actually
> saying is that this WG should go back and fix the ambiguity problem
> created by the Appendix to RFC 2460.
This I think we all agree. I think esp. HW and commercial OS vendors
(roughly similar lead times?) would be grateful to have the ambiguity
resolved.
Jarno
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
