Subject: RE: draft-rajahalme-ipv6-flow-label-00.txt

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 20 Dec 2001 17:16:58 +0100

>   | I don't think that should be allowed.
  > 
  > Huh?   What shouldn't be allowed?   Not having multiple default
  > routers?   That is, you're saying everyone must have more than one?
  > That would be rather ambitious.

=> Indeed, but that's not what I was saying :)
or at least not what I meant. I was arguing
against letting the default routers set the 
flow label and I was saying that 'it' (setting 
the flow label by default routers) should not 
be allowed, or at least not unless somehow
it's restored before the packet is delivered to
the receiver, as per draft-rajahame....

  > I agree as well.
  > 
  > But, if I have only one default router, and I have a lot of 
  > applications
  > that know nothing about setting flow labels (which pretty 
  > much describes all
  > the IPv6 code that exists at the minute that Im aware of), 
  > are you telling
  > me that I am to be prohibited from having the router do 
  > classification and
  > set the flow label to some intelligent choice ?

=> Well the assumption here of course is that 
applications know nothing about the flow label, 
which is fair, considering that it has not been
defined yet. However, once it is defined, I can't 
see why we can't add it to the API and allow it
to be set by the applications. 
Alternatively another part of the stack may
also choose to set it. 

  > 
  > Note: no-one is proposing (that I am aware of) mandating 
  > that it work
  > this way - the issue is more of whether we should be prohibiting it.
  > Personally, I like to prohibit as little as possible, unless there's
  > a very good reason - and that someone (or some group) can't 
  > figure out
  > how they'd sanely use it, isn't good enough.

=> So I guess you're arguing for allowing the 
case where routers can modify the flow label
from zero to X. But should we then force them
to set it back to Zero again ? 
I'm just wondering if there will be any confusion
if the receiver gets a flow label set to X when
the sending node didn't intend to set/use the 
flow label at all.

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

---

From: Robert Elz <[email-masked]>
Date: Fri, 21 Dec 2001 18:03:41 +0700

Date:        Thu, 20 Dec 2001 17:16:58 +0100
    From:        "Hesham Soliman (ERA)" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I was arguing
  | against letting the default routers set the 
  | flow label and I was saying that 'it' (setting 
  | the flow label by default routers) should not 
  | be allowed, or at least not unless somehow
  | it's restored before the packet is delivered to
  | the receiver, as per draft-rajahame....

Well, the draft, as it exists now at least, allows for just the opposite
(in 2 specific cases).   Certainly allowing any more than the two it
allows would not be agreeable with me, but I'm not certain that I can
see a reason to expressly prohibit those two.

Which isn't to say that I can think of a good reason to support them
either - other than that I don't like to prohibit something for no better
reason than that I don't understand it.

  | => Well the assumption here of course is that 
  | applications know nothing about the flow label, 
  | which is fair, considering that it has not been
  | defined yet. However, once it is defined, I can't 
  | see why we can't add it to the API and allow it
  | to be set by the applications. 

Of course.   I haven't gone to check, but I'd be surprised if the
API isn't already there - just unused as no-one knows how to use it
yet.

But once applications exist, and work (for some definition of work)
getting them all upgraded to use new functionality is a very difficult
thing to achieve.

  | Alternatively another part of the stack may also choose to set it.

Yes.   But don't you see how similar this is to having a router set it?
In either case, it won't (shouldn't) be altered if it has been explicitly
set by the application, but assuming the existence of a "not set to anything"
or if you like "I don't care" value (which is the 0 value currently),
if there some particular reason it makes a big difference whether something
down the stack change it, or whether a router does?   In either case, when
the packet arrives at the destination application, it has been changed.

Of course, once altered by anyone, it is no longer at the "unset" value,
and can never be altered again (the other "explicit permission" exception
assumed not to apply)
 
  | => So I guess you're arguing for allowing the 
  | case where routers can modify the flow label
  | from zero to X. But should we then force them
  | to set it back to Zero again ?

Yes, that's it - though "arguing for" is perhaps too strong,
"arguing against prohibiting" would be better.

And I can't imagine why.

  | I'm just wondering if there will be any confusion
  | if the receiver gets a flow label set to X when
  | the sending node didn't intend to set/use the 
  | flow label at all.

I can't think of any reason why it should - I can imagine a receiving
node requiring a flow label to have been set, if it wants to believe
that some specific service quality is somehow being delivered to it,
which an unset label would pretty much guarantee isn't happening, but
I can't imagine why it would care that it explicitly wasn't getting
anything special.

That is, I wouldn't often expect SMTP senders to set flow IDs for most
mail - but nor would I expect a SMTP receiver to object if some sender
decided its mail should get some special treatment.

In general, Tony Hain's arguments are pretty persuasive to me ... but I
am not sure that I would go as far as to prohibit all changes to the
label - though the only ones I would allow are where the source has
explicitly said that changes are OK (which an initial label of 0, or
we could reserve FFFFF for the purpose, could be defined to do, and some
flow state setup mechanism could also do).

Also, everyone please note, just in case it isn't already clear.  When
anyone says the field needs to be immutable (in this case anyway), it
isn't (really) because anyone cares what value is delivered to the
recipient node - it is that we want to know what value will be observed as
the packet passes through each routing domain along the path.   That's
important.  It just happens that this is equivalent to saying that the
field must not be modified (perhaps with some specific exceptions).

Lastly, wrt Margaret's question/suggestion - I think that the IPv6 group
needs to define the basic parameters of the field.  If that isn't done
there are no guidelines for others to use to know what they can and cannot
assume.   In particular, there's nothing to prevent incompatible specs
for the use of the field being developed - ones so incompatible that there's
no way to accommodate both in the internet (and yet perhaps no global way
to prefer one over the other).   So, I certainly feel it is appropriate for
this WG to say whether, and if so when, this field can be modified by routers
along the path.

kre

---

From: Michael Thomas <[email-masked]>
Date: Fri, 21 Dec 2001 08:56:26 -0800 (PST)

> the packet arrives at the destination application, it has been changed.

   I sure see a difference. If my stack does that for me
   I always have the option to cd /usr/src/linux/net/ipv6
   and make it stop doing that; YMMV. In a router, I stop
   having that option.

 > "arguing against prohibiting" would be better.

   I can. It's the slippery slope to MIDCOM.
   If we *really* want to preserve options here,
   let's incoprorate Christian's suggestion that
   we save a couple of bits out of the field which
   define the sematics of the flow lable. The
   beauty of Alex and Jarno's proposal is it's
   simplicity. Mucking with that isn't likely
   to provide anything new, IMO.

	      Mike

---

From: Robert Elz <[email-masked]>
Date: Sat, 22 Dec 2001 00:16:06 +0700

Date:        Fri, 21 Dec 2001 08:56:26 -0800 (PST)
    From:        Michael Thomas <[email-masked]>
    Message-ID:  <[email-masked]>

  |    I sure see a difference. If my stack does that for me
  |    I always have the option to cd /usr/src/linux/net/ipv6
  |    and make it stop doing that; YMMV. In a router, I stop
  |    having that option.

If your router does it, and you don't want it to, you reconfigure the
router, or if that's not possible, you replace it.   If it isn't your
choice to change that, then you're probably attempting to defeat the
policies of your local net.

  |    I can. It's the slippery slope to MIDCOM.

I have learned to largely ignore slippery slope arguments.  They're
mostly FUD.

  |    If we *really* want to preserve options here,
  |    let's incoprorate Christian's suggestion that
  |    we save a couple of bits out of the field which
  |    define the sematics of the flow lable.

Are you paying any attention to what is being suggested?  Really?

  |    The beauty of Alex and Jarno's proposal is it's
  |    simplicity. Mucking with that isn't likely
  |    to provide anything new, IMO.

What I have been describing ie *exactly* what is in their draft
(as it stands now, before any input from the SLC meeting, or this
discussion on the list has had a chance to affect it).

Have you read it?

kre

---

From: Michael Thomas <[email-masked]>
Date: Fri, 21 Dec 2001 10:18:27 -0800 (PST)

> policies of your local net.

   Um, no. I don't want my telephant's local policy --
   which is largely to be as inflexible as
   possible -- to effect end to end semantics. I
   also don't want them to install net nanny's or
   other intelligent network junk either.

 > I have learned to largely ignore slippery slope arguments.  They're
   
   By all means, ignore away. Lots of people think
   that it's a bunch of FUD about NAT's too. They're
   by and large completely ignorant.

 > discussion on the list has had a chance to affect it).

   Yes, yes, big deal. They wanted to support
   first hop rewrite, it got a negative reaction
   and from what I can tell they're not wedded to
   that piece. Do you actually disagree, or are
   you just being argumentative?

	    Mike

---

From: Robert Elz <[email-masked]>
Date: Sat, 22 Dec 2001 18:43:27 +0700

Date:        Fri, 21 Dec 2001 10:18:27 -0800 (PST)
    From:        Michael Thomas <[email-masked]>
    Message-ID:  <[email-masked]>

  |    Um, no. I don't want my telephant's local policy --

Then leave them - they'll never learn as long as people just accept it.

  |    Yes, yes, big deal. They wanted to support
  |    first hop rewrite, it got a negative reaction
  |    and from what I can tell they're not wedded to
  |    that piece. Do you actually disagree, or are
  |    you just being argumentative?

I am trying to find out what the actual harm would be in reserving exactly
one value for the flow-id field with a meaning defined as "I don't care if
this is altered by the network for its purposes".   No-one would have to
use that value if they cared about immutability - just use some different
one.   So far, I see no evidence of harm at all - nothing more than
queasiness at the thought of the network altering anything in a packet,
even when the source host has said it is OK for it to be altered (I'm not
sure how you cope with the hop limit field, or source routing).

Unless someone can show that some actual harm can be caused by by this,
then I'm finding it hard to understand why anyone would want to prohibit it.
It all seems to be a case of "I would never want to use this, therefore
you are not allowed to use it either".

kre

---

From: "Jim Fleming" <[email-masked]>
Date: Sat, 22 Dec 2001 09:17:58 -0600

----- Original Message ----- 
From: "Robert Elz" <[email-masked]>

> sure how you cope with the hop limit field, or source routing).

The "network" is defined by the boundary encompassing all interconnected
systems which exchange packets without changing fields required to make
the "network", the "network", as opposed to a "notwork". If someone or
some company starts changing fields and breaks the "network", then they are
not part of the "network".

IPNG is not IPv6 it is IPv4 with some extensions and changes that do not
break things. There will be many extensions and changes that do not break
anything, and the collection of extensions can be called IPv8. Even the 2002
extended addressing added to IPv4 via AAAA DNS triggers falls into the
IPv4++ or IPv8 C@tegory. All of the TOS, TTL, RIFRAF and other forms
of mangling fall into the IPv8 swamp.

For people wishing to send fields of data from one end of the "network" to
the other, without being changed, there are UDP and TCP formats for that.
You tuck the data inside and it generally does not get changed. If it does
get changed, then that system making the changes falls outside of the "network".
Those systems make up the "swamp", an unstable collection of stuff that
floats between the users and the "network".

At some point, people see the light and emerge from the swamp. They
interconnect. They do that to exchange traffic efficiently in mutually beneficial
locations. That forms another network which tends to be very stable and
something people are not connected directly to and which most people do
not touch. That is the high-ground called IPv16. Good luck in the swamp.

Jim Fleming
http://www.IPv8.info
IPv16....One Better !!
http://www.dot-biz.com/IPv4/Tutorial/
http://www.RepliGate.net
The Netfilter Project: Packet Mangling for Linux 2.4
http://netfilter.samba.org

---

From: Richard Carlson <[email-masked]>
Date: Mon, 24 Dec 2001 09:12:00 -0600

Robert;

How would a receiving host, or the egress router, determine that the FL in 
the arriving packet needs to be reset back to the original value?  Unless 
you can make this happen, the e2e aspect is lost and we're back to the same 
state, the receiver can't tell if the network changed the FL or not.  So I 
agree with Tony, the FL needs to remain immutable and even 1 mutable value 
destroys its value.

Rich

>you are not allowed to use it either".

------------------------------------

Richard A. Carlson				e-mail: [email-masked]
Network Research Section			phone:  (630) 252-7289
Argonne National Laboratory			fax:    (630) 252-4021
9700 Cass Ave. S.
Argonne,  IL 60439

---

From: "Subrata Goswami" <[email-masked]>
Date: Mon, 24 Dec 2001 12:59:36 -0800

One more question. Does immutable flow label also
imply that flow remapping is not supported ? if so
how is that going to be enforced  - it seems to be impossible
to do that. Even the source and destination IP addresses
can be mutated (or changed), right ? NAT is an example
in IPv4.

Subrata

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Richard Carlson
Sent: Monday, December 24, 2001 7:12 AM
To: Robert Elz; Michael Thomas
Cc: Hesham Soliman (ERA); [email-masked];
[email-masked]; [email-masked];
[email-masked]
Subject: Re: draft-rajahalme-ipv6-flow-label-00.txt

Robert;

Rich