Subject: RE: Usage of IPv6 flow label

From: Christian Huitema <[email-masked]>
Date: Mon, 27 Nov 2000 18:38:19 -0800

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-masked]]
> 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-masked]
> --------------------------------------------------------------------
> 
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Nov 2000 10:20:17 -0600

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

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
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-masked]
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Alex Conta <[email-masked]>
Date: Tue, 28 Nov 2000 14:54:39 -0500

Brian,

Brian E Carpenter wrote:
> [...]
> [...]

Brian,

This would allow any router on the path of a packet to apply the same
5-tuple 
classification rules, which is a nice feature.

But, I am not sure why you exclude other ways, like associating a
particular 
value to the 5-tuple, ala MPLS, and have all downstream routers "know"
and 
classify based on that "known" value.

As classification is done for practical purposes to place packets in
distinct processing queues, I have mixed thoughts about the practicality
of
having both source and destination port numbers, and as a matter of fact
the 
5-tuple for that purpose. I wonder in fact, if one would have a straight
answer
on how many router implementations, including IPv4 ones, do per flow
(5-tuple) 
queuing today, or plan to have that in the future.

Alex

>>[....]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Nov 2000 16:47:58 -0600

Alex,

The problem is that any such association is pretty much likely
to disappear across ISP/ISP boundaries, unless there is a global
standard for the semantics. 

  Brian