Subject: RE: AW: AW: Usage of IPv6 flow label

From: "Elwyn Davies" <[email-masked]>
Date: Thu, 30 Nov 2000 15:28:52 -0000

Itojun's example would be covered by DiffServ, and I would argue that it
would not be a good idea to duplicate the DSCP functionality by using the
flowlabel.  In the example, I would really want the whole flow to follow the
same path (and hence expect it to be kept in order) whereas giving different
flowlables to the sub-streams would positively encourage routers to put them
on different streams.  I suspect that for most cases the extra effort of
marking the sub-streams through flow labels might well be left to the kernel
by using multiple sockets - why invent a new means of multiplexing when
TCP/IP provides a ready made one?

Regards,
Elwyn

> -----Original Message-----
> From:	Jun-ichiro itojun Hagino [SMTP:[email-masked]]
> Sent:	Thursday, November 30, 2000 12:19 PM
> To:	Metzler Jochen
> Cc:	[email-masked]'
> Subject:	Re: AW: AW: Usage of IPv6 flow label
> 
> 
> >I am not a kernel specialist, but I assume that from
> >a performance point of view it would be much more performant
> >to have several flows using only one socket instead of 
> >having a single socket for each flow? 
> 
> 	I believe there's no performance issue here.  what kind of
> 	performace drawback do you have in mind?
> 
> 	I can imagine a use of multiple flow label values for single TCP/UDP
> 	session, if:
> 	- a single TCP session includes traffic with different
> characteristics,
> 	  for example, MPEG key frames (full picture) and intermediate data
> 	  (differences between Nth full picture to (N+1)th full picture)
> 	- the application would like to enforce different RSVP
> characteristics
> 	  to key frames and intermediate data.
> 	- so, application would like to label packets with key frames with
> flow
> 	  label X, and intermediate data with flow label Y.  packets with
> flow
> 	  label X will have a higher priority than those with flow label Y.
> 	i'm not sure if the above example makes sense or not.
> 	even if the example is okay, there's absolutely no kernel
> performance
> 	issue here.  the reason why we use two flow label values (X and Y)
> 	is from the applicatoin needs, not from kernel performance issues.
> 
> >An other concern is the redundancy of information in 
> >ports and labels. 
> 
> 	as i noted in previous messages, the purpose of flow label value is
> 	to provide quick lookup of L4 port pair and protocol type.  so
> 	I would say that the redundancy is expected.  the redundancy is
> 	what we really want - intermediate routers do not want to chase
> 	extension headers to find L4 header.
> 
> itojun
> --------------------------------------------------------------------
> 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: [email-masked]
Date: Fri, 01 Dec 2000 00:33:58 +0900

>flowlabel.

	I'm not trying to talk about diffserv.

itojun

---

From: Michael Thomas <[email-masked]>
Date: Thu, 30 Nov 2000 08:04:38 -0800 (PST)

Elwyn Davies writes:
 > on different streams.  

I'm not sure I buy this. While taking different
routes wouldn't help TCP especially, SCTP and UDP
applications do not suffer from head of line
blocking, and therefore this may not be an issue.

I think there's a larger issue here: DSCP gives a
means of marking a traffic aggregate into a small
set of PHB's and thus relieve interior routers of
the need to keep uFlow state. This is general
goodness. However, there are still uses for uFlows
that the Intserv model provides, and when you
throw RSVP aggregation into the mix along with the
ability to signal for diffserv flows (RFC 2997, I
think), I think you get a pretty flexible mix
to deploy qos enabled networks.

So the real question to my mind is not whether the
flowlabel might be gratuitously supplanting the
DSCP. I can see no reason for this, and would not
support it. However, what _does_ seem to be
interesting -- which is how I read Itojun's
article -- is whether it would be useful to 
have an _alternate_ means of flow classification
for uFlows than the normal 5-tuple.

One of the benfits is that a host could decide
which traffic to bind together as a flow for
a particular tspec, rather than be rigidly
bound to the 5-tuple and needing to set up
separate reservations if you have two or
more flows which don't match that classifier.

This seems like an interesting possibility to
me. From a resource standpoint, the only thing the
routers care about is the tspec.  How a particular
host divvies up the bits policed to that tspec is
not especially interesting to the router assuming
that the router doesn't have to do too much work
to do complex classification... which is something
that the flowlabel promises to be much better on.

	 Mike

I suspect that for most cases the extra effort of
 > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
 > <HTML>
 > <HEAD>
 > <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
 > <META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2652.35">
 > <TITLE>RE: AW: AW: Usage of IPv6 flow label</TITLE>
 > </HEAD>
 > <BODY>
 > 
 > <P><FONT COLOR="#FF0000" SIZE=2 FACE="Arial">Itojun's example would be covered by DiffServ, and I would argue that it would not be a good idea to duplicate the DSCP functionality by using the flowlabel.&nbsp; In the example, I would really want the whole flow to follow the same path (and hence expect it to be kept in order) whereas giving different flowlables to the sub-streams would positively encourage routers to put them on different streams.&nbsp; I suspect that for most cases the extra effort of marking the sub-streams through flow labels might well be left to the kernel by using multiple sockets - why invent a new means of multiplexing when TCP/IP provides a ready made one?</FONT></P>
 > 
 > <P><FONT COLOR="#FF0000" SIZE=2 FACE="Arial">Regards,</FONT>
 > <BR><FONT COLOR="#FF0000" SIZE=2 FACE="Arial">Elwyn</FONT>
 > </P>
 > <UL>
 > <P><FONT SIZE=1 FACE="Arial">-----Original Message-----</FONT>
 > <BR><B><FONT SIZE=1 FACE="Arial">From:&nbsp;&nbsp;</FONT></B> <FONT SIZE=1 FACE="Arial">Jun-ichiro itojun Hagino [SMTP:[email-masked]]</FONT>
 > <BR><B><FONT SIZE=1 FACE="Arial">Sent:&nbsp;&nbsp;</FONT></B> <FONT SIZE=1 FACE="Arial">Thursday, November 30, 2000 12:19 PM</FONT>
 > <BR><B><FONT SIZE=1 FACE="Arial">To:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=1 FACE="Arial">Metzler Jochen</FONT>
 > <BR><B><FONT SIZE=1 FACE="Arial">Cc:&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=1 FACE="Arial">[email-masked]'</FONT>
 > <BR><B><FONT SIZE=1 FACE="Arial">Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT></B> <FONT SIZE=1 FACE="Arial">Re: AW: AW: Usage of IPv6 flow label</FONT>
 > </P>
 > <BR>
 > 
 > <P><FONT SIZE=2 FACE="Arial">&gt;I am not a kernel specialist, but I assume that from</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt;a performance point of view it would be much more performant</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt;to have several flows using only one socket instead of </FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt;having a single socket for each flow? </FONT>
 > </P>
 > 
 > <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">I believe there's no performance issue here.&nbsp; what kind of</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">performace drawback do you have in mind?</FONT>
 > </P>
 > 
 > <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">I can imagine a use of multiple flow label values for single TCP/UDP</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">session, if:</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">- a single TCP session includes traffic with different characteristics,</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">&nbsp; for example, MPEG key frames (full picture) and intermediate data</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">&nbsp; (differences between Nth full picture to (N+1)th full picture)</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">- the application would like to enforce different RSVP characteristics</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">&nbsp; to key frames and intermediate data.</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">- so, application would like to label packets with key frames with flow</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">&nbsp; label X, and intermediate data with flow label Y.&nbsp; packets with flow</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">&nbsp; label X will have a higher priority than those with flow label Y.</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">i'm not sure if the above example makes sense or not.</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">even if the example is okay, there's absolutely no kernel performance</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">issue here.&nbsp; the reason why we use two flow label values (X and Y)</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">is from the applicatoin needs, not from kernel performance issues.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2 FACE="Arial">&gt;An other concern is the redundancy of information in </FONT>
 > <BR><FONT SIZE=2 FACE="Arial">&gt;ports and labels. </FONT>
 > </P>
 > 
 > <P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">as i noted in previous messages, the purpose of flow label value is</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">to provide quick lookup of L4 port pair and protocol type.&nbsp; so</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">I would say that the redundancy is expected.&nbsp; the redundancy is</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">what we really want - intermediate routers do not want to chase</FONT>
 > <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2 FACE="Arial">extension headers to find L4 header.</FONT>
 > </P>
 > 
 > <P><FONT SIZE=2 FACE="Arial">itojun</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">--------------------------------------------------------------------</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">IETF IPng Working Group Mailing List</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">IPng Home Page:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<U> </U></FONT><U><FONT COLOR="#0000FF" SIZE=2 FACE="Arial"><A HREF="http://playground.sun.com/ipng" TARGET="_blank">http://playground.sun.com/ipng</A></FONT></U>
 > <BR><FONT SIZE=2 FACE="Arial">FTP archive:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</FONT><U> <FONT COLOR="#0000FF" SIZE=2 FACE="Arial"><A HREF="ftp://playground.sun.com/pub/ipng" TARGET="_blank">ftp://playground.sun.com/pub/ipng</A></FONT></U>
 > <BR><FONT SIZE=2 FACE="Arial">Direct all administrative requests to [email-masked]</FONT>
 > <BR><FONT SIZE=2 FACE="Arial">--------------------------------------------------------------------</FONT>
 > </P>
 > </UL>
 > </BODY>
 > </HTML>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Nov 2000 10:57:30 -0600

itojun,

>         I'm not trying to talk about diffserv.

I think we need a solution that works for diffserv with ESP.
A solution that only helps IntServ is insufficient.
(DiffServ without ESP doesn't need the flow label
as far as I can see).

So I would actually like something along the lines of Alex's
proposal, but with some differences:

- lose the "IANA assigned" option; replace it by pseudo-random
  numbers as originally defined. Your draft and Jochen's fit right in
  with this.

- figure out a way to make the other option in Alex's draft:

      0                   1
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |0|  Server Port Number| H-to-H protocol|
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

suitable for use by policy-driven diffserv classifiers. 

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