Subject: RE: IPv6 Flow Label Specification

From: [email-masked]
Date: Wed, 10 Jul 2002 14:47:55 +0300

Hi Margaret & authors,

A high-level question - I think that many of your comments could/should
be handled by applications which use the flowspec.  I am not so sure
that the draft, draft-ietf-ipv6-flow-label-02.txt, should define 
these things.

For example, I much prefer that the application (or signaling
protocol) set the following:

	1) cached flow info timeout
	2) re-use of flow label values

Additionally, signaling protocols making use of the flow spec should (must?)
define how routers are expected to use the flow label.

In NSIS, we are starting to discuss these issues, and I would worry if
the IPv6 WG goes into too much detail with regards of how the flow label
is used, etc.

thanks,
John

> -----Original Message-----
> From: ext Margaret Wasserman [mailto:[email-masked]]
> Sent: 10 July, 2002 03:29
> To: Rajahalme Jarno (NRC/Helsinki); Steve Deering; Alex Conta; Brian
> Carpenter
> Cc: [email-masked]
> Subject: IPv6 Flow Label Specification
> 
> 
> 
> Hi Jarno, Steve, Alex and Brian,
> 
> I have a couple of questions about the latest IPv6 Flow Label
> Specification <draft-ietf-ipv6-flow-label-02.txt>.
> 
> First, do you intend this specification to be mandatory for all
> IPv6 nodes?  I would prefer a statement that nodes SHOULD 
> implement this specification, and that nodes that do not implement
> this specification MUST set the flow label in all originated 
> packets to zero.
> 
> Also, should we define a default timeout for cached flow information
> (i.e. 10 minutes)?  This would allow nodes to free information on
> "recent" flows in a consistent fashion, when no signalling or other
> mechanisms are available to indicate how long a flow could live.
> 
> Could you also indicate whether the information about previous
> flows needs to survive TCP/IP restarts and/or node reboots?
> 
> Previous discussions of the flow label have centered around its
> potential use for load sharing -- allowing a router to keep 
> flows together when choosing between alternate paths.  Is that
> still an expected use of this mechanism?  How does this fit with
> the requirement in section 5, bullet (1): "The flow state 
> establishment
> mechanism MUST covey this classifying information to the IPv6 nodes
> that need to perform the classification".  Is a load sharing router
> a degenerate case where the information only needs to be conveyed
> to the router itself?  Could you maybe add this example to the
> document, and explain how it fits into each area of requirement?
> 
> Will hosts reuse a flow label if an application indicates that they
> shoud?
> 
> I'm still concerned about how/if routers may cache forwarding
> information based on the flow label.  Is it you intention that this
> would be an acceptable use?  What about security information?  
> It still seems to me that acceptable uses of the flow label are
> tied to just how certain we can be that the flow triplet (label,
> src address and dest address) will actually identify a single flow.
> And, this means that we would have to have some detailed requirements
> for how/if flow labels are reused.
> 
> Margaret
> 
> 
> 
> --------------------------------------------------------------------
> 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: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Jul 2002 14:41:17 +0200

John,

I agree. The basic spec should be lean and mean. Do you see anywhere that
we have over-defined things?

   Brian

---

From: Pekka Savola <[email-masked]>
Date: Wed, 10 Jul 2002 16:21:54 +0300 (EEST)

On Wed, 10 Jul 2002 [email-masked] wrote:
[...]
> protocol) set the following:
[...]
> 	2) re-use of flow label values

(Hopefully I didn't misunderstand this point.)

The flow label space is far from infinite.  It's hypocritical to believe a
node would not need to consider a case when it needs to start using some
flow labels that may have been previously used.

This is especially important if the implementation should keep track of
flow labels across reboots.  I see no good way of doing this except
writing the labels in some kind persistent storage.  And consider
operating system crashes etc. where this may not be possible.  The only
sane way seems to be to use random flow labels (or at least randomize the
point where to begin using flow labels after a reboot); there are no
problems if one does not have too high expectations of the lifetime of the
uniqueness.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: [email-masked]
Date: Wed, 10 Jul 2002 22:26:25 +0900

>problems if one does not have too high expectations of the lifetime of the

	i completely agree with this statement.  can't always reliably keep
	flow label value into persistent store, so something like "start from
	random number on reboot, and monotonically increase value" makes
	more sense.

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Jul 2002 17:27:24 +0200

>         random number on reboot, and monotonically increase value" makes

I don't see that. Transaction processing systems and databases have this
requirement too, and in "normal" crashes they have no problem, because a
transaction ID is always saved in stable storage before it's used. (I agree
that if you do have to restart the allocation process for some reason, a
pseudo-random seed is good.) 

But in any case, IMHO we have no business specifying any of this
in a basic protocol spec. As John said, it depends on the application 
scenario. I can well imagine a case where an application might want to use
the same flow label for a consecutive flow; there's nothing in the spec
to forbid that, I hope. 

  Brian

---

From: Rob Austein <[email-masked]>
Date: Wed, 10 Jul 2002 13:30:14 -0400

> problems if one does not have too high expectations of the lifetime of the

I agree with Pekka and itojun.

Please also recall that there exist toaster-class devices whose only
persistant storage is flash RAM or some similar technology that has a
finite number of write cycles before becoming, well, toast.  In such
environments preserving frequently-changing data across reboots is not
a trivial matter, and I'm not convinced that flow labels pass the
cost/benefit test.
--------------------------------------------------------------------
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: Bob Hinden <[email-masked]>
Date: Wed, 10 Jul 2002 11:58:38 -0700

Rob,

I think something with similar properties to TCP's initial sequence number 
selection would be about right.  A toaster-class device will have to deal 
with that as well.

Bob

---

From: Rob Austein <[email-masked]>
Date: Wed, 10 Jul 2002 16:40:48 -0400

> selection would be about right.  A toaster-class device will have to deal 

I agree that the constraints seem similar.  ISN selection is another
one of those cases where stable storage vs (good) random numbers is a
tricky question, at least in the toaster universe.
--------------------------------------------------------------------
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: Pekka Savola <[email-masked]>
Date: Thu, 11 Jul 2002 08:58:02 +0300 (EEST)

> selection would be about right.  A toaster-class device will have to deal 

Exactly (to the latter sentence).
 
HOWEVER, note that TCP ISN is not conserved across reboots.  So, in 
practise, a toaster-class device deals with it by not dealing with it.

The same would be good for flow labels.

I agree 100% with Rob that we have to justify flow label storage
__really__ hard to make it something that must be conserved across boots.  
Actually I don't recall anything in the current IPv4 base TCP/IP
specification which requires storage (apart from addresses etc. which are
a non-issue).

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Jul 2002 10:59:27 +0200

> tricky question, at least in the toaster universe.

All of which tells me that if we define a requirement for the flow label
allocation process to survive reboots, it will be a SHOULD not a MUST. 
A toaster would provide a compelling argument for overriding the SHOULD.

But right now we have enough dispute about it that I'd rather leave it
open in the spec, i.e. no change to the draft.

  Brian

---

From: Michael Thomas <[email-masked]>
Date: Thu, 11 Jul 2002 09:31:13 -0700 (PDT)

> open in the spec, i.e. no change to the draft.

   FWIW, I agree with Brian.

	   Mike

---

From: Rob Austein <[email-masked]>
Date: Thu, 11 Jul 2002 09:30:53 -0400

> A toaster would provide a compelling argument for overriding the SHOULD.

Precisely.

> open in the spec, i.e. no change to the draft.

Fair enough.