Subject: Re: Flow Label

From: Brian E Carpenter <[email-masked]>
Date: Wed, 02 Jan 2002 13:50:48 +0100

[this also responds to Scott's comments, I think]

"Perry E. Metzger" wrote:
> 
> Michael Thomas <[email-masked]> writes:
> > Perry E. Metzger writes:
> >  > > Sorry, the SPI is no good for diffserv classification
> >  > > because it has no semantics.
> >  >
> >  > Neither does the flow label. Both are just a number that can be used
> >  > to distinguish a bunch of traffic flowing between two hosts from other
> >  > traffic flowing between two hosts. Neither has any semantics beyond
> >  > that.
> >
> >    Bzzt. You're overloading semantics. SPI's enumerate
> >    the set of packets for which a given security policy
> >    applies. That may have exactly zero to do with the
> >    QoS policies you'd like to apply.
> 
> In the scheme proposed, flow labels just enumerate a set of packets
> that a host has chosen to designate as a "flow" because, say, they're
> all using the same TCP socket -- which may also have exactly zero to
> do with the QoS policies you'd like to apply. How is it any different
> than the SPI situation?

In the intserv case, it is no different. In the diffserv case, the presumption
is that we would use IANA-assigned, globally meaningful values, that are
specific to a desired QOS treatment rather than to any individual traffic flow.
The implementation details (including the DSCP value and router configurations)
may differ from ISP to ISP, but the flow label bits convey end to end
semantics. This is more powerful than port numbers whose semantics are poor at
best for QOS purposes, and it works when the port numbers are invisible.

> 
> >  > > I didn't say it makes no difference. I said that the difference is more
> >  > > likely to be in cost and waste heat than in speed.
> >  >
> >  > Given that the manufacturers who are doing this are already building
> >  > the transistors in to walk the header chain...
> >
> >    By all means, let's just ignore silicon considerations.
> >    Moore's Law trumps all, obviously.
> 
> If they have to build tuple extraction into the hardware anyway to
> deal with the implementations that don't do flow labels (i.e any
> deployed in the next few years), how can we claim that we're going to
> get around people having to build hardware? Given that several vendors
> have already designed the hardware, how are we going to be helping?

Hardware gets updated. The point of giving the flow label a clear definition
is to allow hardware designers to build classifiers that include the flow label
as one of the fields used for line-speed classification. What the next level
up in the hardware/firmware/software does with the classified packets
is a separate question.

   Brian

> 
> --
> Perry E. Metzger                [email-masked]
> --
> NetBSD Development, Support & CDs. http://www.wasabisystems.com/

--------------------------------------------------------------------
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: Randall Stewart <[email-masked]>
Date: Wed, 23 Jan 2002 07:21:17 -0600

Catching up on a real old email...

Michael Thomas wrote:
>    Also: you seem to be under the illusion that
>    QoS classifiers are set in stone. They are not.
>    I just took a quick look at SCTP: its ports

Michael:

Your quick look was just that .. a very quick look :>

From RFC2960 (the first bytes in the packet look as follows
and are called the common header):
"
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Source Port Number        |     Destination Port Number   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Verification Tag                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Checksum                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

"

From RFC793:
"
  TCP Header Format

    0                   1                   2                   3   
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Source Port          |       Destination Port        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Sequence Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Acknowledgment Number                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Data |           |U|A|P|R|S|F|                               |
   | Offset| Reserved  |R|C|S|S|Y|I|            Window             |
   |       |           |G|K|H|T|N|N|                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Checksum            |         Urgent Pointer        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Options                    |    Padding    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             data                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
"

The byte postion looks pretty close to the same as far
as I can tell :>

R
>    are not in the same place as TCP/UDP; hence,
>    hardware change. Each new IP protocol that we
>    come up with will have the same problem. The
>    flow label has the potential to stop that
>    problem now and forever.
> 

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)