Jim,
Could you help my memory on Steve's counter arguments? From the meeting
minutes I just read that you "agree with Steve's position". Also, according
to the minutes, while the division in two was similar, there is a difference
in the intended semantics between your proposal and Brian's ("Router owns
it" vs. "Non-unique value").
Anyway, I kept thinking about this over the weekend. I think we just need to
agree on what a "flow" is, or what it could be. In intserv we have
"micro-flows" (being specified by the 5-tuple). In 2460 App.A we have an
"app-to-app" flow, which is agnostic to the transport header stuff, but
needs to be given the same forwarding treatment (including routing).
(Since the first is a subset of the second, we only need the "app-to-app"
flow, as the micro-flow can be achieved by a host convention of mapping 1:1
between a 5-tuple and a flow label.)
I think we could have a new kind of flow, a "well-known flow". The prime
example of this kind of the flow is the one with flow label '00000'. For
these the source only requests the same forwarding treatment, but naturally
excluding routing if destination addresses are different. The state for
these flows could be either SLA based or signaled.
For administrative reasons the flow label name space should be split in two,
as Brian proposed, but with the MSBs reversed: MSB='1' for 2460 App.A flow
(but without the PRN requirement), MSB='0' for the "well-known flows".
As discussed, the "well-known flow label" should be immutable as well as the
"app-to-app" flow label. (We do not need another DSCP field.)
The "well-known flow label" would be an end-to-end construct, and would be
meaningful only in a context of a (transitive) business relationship to
either the source or the destination. This means that an ISP would only look
at the flow label, if a customer tells it to. The SLA (or signaling or
whatever) binding together a (range of) source address(es), a (range of)
destination address(es), and a specific "well known flow label", would also
tell what to do with the packets of the flow.
The property of being "well-known" would help otherwise unrelated end points
to agree on what values to use (without signaling), and enable off-line
configuration of those diffserv reclassifiers on domain entry.
What Brian has proposed is that a portion of the "well-known flows" name
space to be allocated to PHB-IDs. Others could have other ideas for
well-known flow labels (like Christian's "traffic type"). Inevitably the
specification of the well-known flow label hints at the intended semantics,
but it should be clear that the semantics is meaningful only if a "paying"
customer can be identified (directly or indirectly), and even then the
customer tells what to do with the packet (E.g. Could map an AF-PHB-ID flow
label to EF DSCP value).
In some business arrangements between an end user and an ISP, usage of
specific "well-known" flow labels could result in a better service and incur
additional charges. Therefore the use of the "well-known" flow labels must
be separated from the usage of the well-known ports of the transport layer.
Also, it may be that the user wants to pay extra for the delivery of some
packets over e.g. HTTP, but NOT for others.
As for the HW implementations, it seems that wildcard source address for
matching a packet with a "well-known flow label" doesn't make too much sense
(*). So, the implication would be that your lookup needs to be agnostic of
the flow label format altogether, just treat it as 20 bits of random (but
not PRN) data. The data you find should tell what to do with the packet. The
SLAs and intserv signaling is used to populate that data.
(* In the beginning of the path, you need to know who is sending the packet
(to decide whether to do what the flow label asks for). At the end of the
path, the customer doesn't want to pay extra for some random hacker sending
packets with a "well-known flow label". So, in both cases, the source
address needs to be "in range".)
>From the IPv6 WG perspective the only difference between the two forms is
the missing 'routing' aspect of the forwarding treatment based on the
well-known flow label (same label can be used in packets to multiple
destinations. The state establishment for the actual use of the flow labels
is outside of the IPv6 WG scope (IMO).
So, once defined as a concept, the definition of the actual "well-known
flow-label" values should not be a critical issue for the IPv6 WG. Naturally
any large scale benefits of the concept depend on widely agreed upon
definitions, but even single "big customers" could have specific values as
part of their SLAs with their ISPs.
Jarno
> -----Original Message-----
> From: ext Jim Bound [mailto:[EMAIL PROTECTED]]
> Sent: 31. elokuuta 2001 19:20
> To: Brian E Carpenter
> Cc: ipng
> Subject: Re: Another idea for the flow label
>
>
> Brian et al,
>
> A lot of mail but lots of it are repeating. The only way my change in
> vote for "c" will work is if we do this below per Brian. But
> I presented
> this case in front of the IETF WG at Minneapolis and folks
> did not want to
> go there and Steve presented good counter arguments to doing
> it. It is a
> compromise to do the below.
>
> A few statements:
>
> Immutable field: I agree with Tony 100% if we have a per microflow it
> should be immutable for that option and I mean in the strongest sense
> that it is read-only. I will not post my reasons again but
> they are in
> line with Tony and also that I am not comfortable saying
> nodes along the
> path will return the field to its former value. AT
> ALL.......Causing bugs
> with per microflows for apps that depend on it is something I
> could never
> support and to trust the edge and core with that without how its to be
> done is a bit of a stretch for me and I think for any IETF
> specifications
> sound protocol effect on networks. Immutable field is the
> quickest way to
> standards track I would argue for per micro-flows. In the
> future after
> some practical experience that could be re-discussed.
>
> MF Classifiers: We should solve this problem so that all
> classification is
> done only at the header. The multiple tuple value for classification
> beyond the header in Diffserv architecture was a huge mistake
> to put in
> the model and having boxes look at L4+ values is bordering
> absurdity IMO.
>
> IETF Rants we need to support QOS other standards: This is
> simply bogus
> logic. As Bob said the place to change our rules is in
> POISED not IPng.
> If Diffserv made a mistake or neglected to deal with cases
> like IPsec that
> does not mean IPv6 WG MUST support fixes to make it work. That is the
> bogus logic. It assumes a rule for us in IPv6 WG which DOES
> NOT EXIST.
> Arguing it may be the right thing to do is fair. I don't
> agree though.
>
> Are we getting anywhere? After working on this for many
> years I feel NO.
> The bottom line is can the IPv6 WG agree to the attached compromise in
> some form? That should be the first thing we have to agree
> on or Thomas
> is correct we need to just leave it alone for awhile till we can get
> consensus. We don't have it now IMO.
>
> Should we use the flow for other than QOS? I think that is a
> wise vision.
> But then we need some kind of compromise for that too.
>
> /jim
>
>
> On Tue, 28 Aug 2001, Brian E Carpenter wrote:
>
> > How would people feel about this encoding for the flow label
> > (deemed to be immutable end to end)?
> >
> > 0 1
> > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |0| Per-microflow unique value |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> >
> > 0 1
> > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> > |1| Non-unique value |
> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >
> > I'm not yet 100% convinced that the second case is sufficient for
> > diffserv, but at least it would be a more generic approach
> > than reserving half the space for 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]
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
>
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
