Subject: Re: Flow Label

From: Robert Elz <[email-masked]>
Date: Fri, 18 Jan 2002 12:55:58 +0700

Date:        Thu, 17 Jan 2002 12:45:24 +0100
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | In any case, the behaviour when you see an "unknown" flow label should be
  | the same as when you see a zero label - apply default treatment, whatever
  | that happens to be locally. No need to either drop the packet or
  | rewrite the label; at that point it's just a noise field.

Yes, of course.

kre

--------------------------------------------------------------------
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: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 11 Jan 2002 10:02:46 -0500

In message <[email-masked]>, Brian E Carpenter writes:
>Indeed. All of this is the same for the DSCP actually, and the
>assumption is that operators will protect themselves with
>admission control.
>
>(See sections 7.1 of RFC 2474 and 6.1 of RFC 2475 for detailed discussion)
>

Right.  The question now is how to do that.  I was about to agree 
strongly with the "must send as zero if not a flow, routers must not modify"
until I started thinking along these lines.  What should a border 
router do with a packet that doesn't meet its constraints?  I only see 
three choices:  reset the flow label to something locally acceptable, 
drop the packet, or tunnel.  But dropping the packet means that flow 
labels can only be used for flows that stay within a particular flow 
label domain, and the tunneling path leads to madness.  (Well, perhaps 
to MPLS, but I don't think we want to go down that rathole now.)  I'm 
forced to conclude that we have two choices:  either we give up on flow 
labels entirely, or we permit them to be modified en route.

		--Steve Bellovin, http://www.research.att.com/~smb
		Full text of "Firewalls" book now at http://www.wilyhacker.com

---

From: Michael Thomas <[email-masked]>
Date: Fri, 11 Jan 2002 12:08:21 -0800 (PST)

> labels entirely, or we permit them to be modified en route.

   First of all, there's nothing that is defined
   from which to take action based on the flow label,
   so I think this is largely an academic question.
   If we suspend some disbelief and posit an edge
   device which, say, polices a flow to a particular
   rate, why does it follow that the router would 
   need the ability to rewrite the label? Certainly
   in the Intserv case, policers don't rewrite the
   5 tuple. Their only option is to change the PHB
   or drop it. In diffserv style, it can in addition
   to dropping and changing its queuing characteristics, 
   rewrite the DSCP.

   So I guess I just don't see where a policer
   would need the ability to alter it. Also:
   pragmatically, we can alway change our mind
   on the mutability front if it starts life as
   *immutable*.

		Mike

---

From: Robert Elz <[email-masked]>
Date: Mon, 14 Jan 2002 21:03:12 +0700

Date:        Fri, 11 Jan 2002 10:02:46 -0500
    From:        "Steven M. Bellovin" <[email-masked]>
    Message-ID:  <[email-masked]>

  | But dropping the packet means that flow 
  | labels can only be used for flows that stay within a particular flow 
  | label domain,

No, you have accepted one of Margaret's arguments, taken that to its
logical conclusion, and reached absurdity, so obviously, something has
to be wrong.

But it isn't the immutability that's wrong, it is the assumption that
different QoS mechanisms can redefine the flow label field in different
incompatible ways.

That simply cannot be allowed to happen, or any kind of usable QoS is
even less likely to ever get deployed than the small chance there seems
to be at the minute.

There has to be (absolutely) one fixed consistent definition for the
field, that all QoS mechanisms (now or in the future) can live with.
If anyone needs some extra data that doesn't fit, they simply have to
put that data elsewhere.   If after doing that the flow label is useless
to them, then they just don't use it.

Exactly what the one fixed definition should be, I'll leave it to others
to sort out, but there has to be exactly one - your analysis of what
happens if things are allowed to become inconsistent shows that.

Allowing routers to change the flow label to make it "legal" doesn't
help - apart from simply making it say "unclassified" (which they could
do just as easily by putting a magic value defined by them in the DCSP)
from where would they get the information to install any other value.

But if you can assume they can invent it from somewhere, then you need
to work out how to handle the case where my packets flow through 3
independent ISPs, A B and C.   I deal directly with A, so I can easily
provide a flow label that suits A's requirements.   If B doesn't like that,
and changed it to something that fits B's requirements, what on earth
happens when the packet reaches C?   At that point, C has no idea what
the flow label might mean - it could be something I put there, or it could
be something local of B's.

That's simply impossible to support.   C has to know what the value
represents (whether that then results in any special handling or not is
up to whatever agreements exist among  the various parties, and what they
say - but regardless of that, if there's no way for C to interpret the
request, then agreements would be useless).

kre