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