Subject: Re: IPv6 Flow Label Specification

From: Robert Elz <[email-masked]>
Date: Wed, 17 Jul 2002 14:52:13 +0900

This doc is mostly OK, but if it is going to specify that the
flow label be unique (within the source/dest addr space), it also
needs to specify for how long that needs to remain true.

Comparisons with TCP ISN's have been made, and that's fine - but
with TCP, the period within which an ISN should not be reused is
known - one technique a TCP implementation can use, other than
stable storage (or other ways) is simply to abstain from using
any ISNs (that is, from sending packets) for a set period after
a restart.

While that's hard for TCP, and so few implementations these days
actually force the node to remain silent for minutes after a restart,
with flow labels, the existence of the 0 value, mitigates this,
and would allow a node to simply not use flow labels for a period
after a restart.   But only if we have some idea what that period
is to be.

There has to be a period, or after 2^20 - 1 flows between a source and
a destination, there could never be another.

The period needs to be explicit (either a constant, or algorithmically
derivable).   Stacks need to know what it is, and routers need to have
some guidance on how long idle state might usefully be retained (without
constraining them, beyond what the flow setup protocol does, to actually
do anything at all with flows).

When we get to APIs (the other issue discussed here recently), I
suspect that we're going to need a mechanism to set a specific value
as the flow label (and the application would be resonsible for
ensuring it was valid to use), a mechanism to simply set a new flow
label, without caring about its value (in which case the stack would
apply the uniqueness constraint - which might then mean dividing the
flow label space (for that stack) into some available for apps to
set, and some for the kernel, or the bookkeeping would get real hard),
and a mechanism to set no flow label.   This can't be directly died to
sockets, as multiple of those might want to be using the same label
(though one way to do that would be to have a label picked, then a method
to obtain the value selected, then force that into the other sockets).
Nor can it be tied to bind/connect sys calls - the lifetime of a label
and the lifetime of a TCP connection (or the thing which UDP gets when
connect is used) aren't necessarily related.  Using those to supply
default labels, when there is no other app request, would mean mods to
less applications though.

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: [email-masked]
Date: Wed, 17 Jul 2002 16:13:18 +0900

>less applications though.

	i don't think we need to un-tie flowlabels and sockets, at least
	within the default behavior.  it complicate things too much (and if we
	add a new system call, we'll need to go through POSIX/XNET/whatever,
	which will be a lot of pain).
	for normal usage 1:1 relationship between socket and flowlabel should
	be ok.  i'll try to think more about how i should provide user
	override for flowlabel values.

itojun

---

From: Robert Elz <[email-masked]>
Date: Wed, 17 Jul 2002 18:23:40 +0900

Date:        Wed, 17 Jul 2002 16:13:18 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	i don't think we need to un-tie flowlabels and sockets, at least
  | 	within the default behavior.  it complicate things too much (and if we
  | 	add a new system call, we'll need to go through POSIX/XNET/whatever,
  | 	which will be a lot of pain).

Oh sorry, I obviously wasn't very clear.   That degree of breaking the
relationship wasn't what I intended.   Using setsockopt() or similar
will be just fine.   All I meant was that there shouldn't be a one flow
label to one socket assumption anywhere.  Several sockets might be
using the same flow label (and not just ones in the unix world split
by dup()/fork() semantics) and one socket might use different labels
at different times (within the same transport level connection).

  | 	for normal usage 1:1 relationship between socket and flowlabel should
  | 	be ok.

Yes, most of the time, for most apps, that will be fine.   But we do
need to provide for the exceptional cases too.

kre

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Jul 2002 12:14:21 +0200

One of the coauthors agrees with you about the need for
a defined timer. But I was talked out of it. Let's hear
what the WG thinks about this.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Jul 2002 15:34:42 +0200

fwiw, I fully agree with kre

   Brian