Christian,
All three modes of operation of diffserv that you mention are possible,
implemented,and in experimental use. But there is a problem:
a) we expect ISPs to classify, police, re-mark and shape traffic at their
ingress, regardless of what the originating host or the first border
router may have done
b) that classification will be done in accordance with an ISP-specific
policy expressed in some subset of {address range, port #, protocol #}
c) this is impossible for IPSEC encrypted packets
d) a syntax and semantics for the flow label that could be used
by a classifier would fix this
e) the only way I can see to do this is to compress port # and protocol #
information into the flow label.
I do intend to read the recent drafts so I'd better shut up until then.
Brian
Christian Huitema wrote:
>
> Brian,
>
> I am a bit puzzled by your reference to the 5 tuple as "enabling diffserv."
> I think you have a model there in which the diffserv bits are set by some
> intermediate router, after examining the "5 tuple" of the packet. In this
> context, the five-tuple works somewhat. But it does not work well with IPSEC
> (ports are hidden), it does not work well with floating port applications
> such as VoIP, and it leads to some interesting header manipulation when we
> encounter stacks of IPv6 headers.
>
> There are at least two other ways to "enable diffserv." One way would be to
> just let the hosts set the diffserv bits, and then let the intermediate
> router do accounting, charging, and maybe rationing. Another way is to use
> RSVP to convey the requested quality of service, and the user credentials,
> to the intermediate routers; then, the flow-id can be use for flow
> classification, and the intermediate routers can on this basis set the
> diffserv bits however they see fit.
>
> -- Christian Huitema
>
> > -----Original Message-----
> > From: Brian E Carpenter [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, November 27, 2000 2:49 PM
> > To: Michael Thomas
> > Cc: Jim Bound; Ipng (E-Mail)
> > Subject: Re: Usage of IPv6 flow label
> >
> >
> > Michael Thomas wrote:
> > >
> > > Brian E Carpenter writes:
> > > > Jim,
> > > >
> > > > It still isn't clear to me what the flow label adds to
> > the semantics
> > > > used by existing 5-tuple QOS classifiers.
> > >
> > > It seems intuitively more efficient for a flow classifier
> > > to use a single host-defined flow identifier than having
> > > to walk a potentially long list of extension headers.
> > > Another advantage is that, sort of like diffserv, the
> > > host itself can decide what is to be grouped in a particular
> > > flow instead of requiring that it match the normal 5-tuple.
> >
> > Just to make the point again: the 5-tuple has semantics that
> > allows a classifier to *classify* the traffic. Today at least,
> > the flow label has no such semantics - it's just plain bits.
> > That may help in IntServ but it's no use at all in DiffServ.
> >
> > 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]
> > --------------------------------------------------------------------
> >
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Program Director, Internet Standards & Technology, IBM
On assignment for IBM at http://www.iCAIR.org
Board Chairman, Internet Society http://www.isoc.org
Non-IBM email: [EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
