Subject: AW: Usage of IPv6 flow label

From: Metzler Jochen <[email-masked]>
Date: Thu, 30 Nov 2000 11:18:08 +0100

Hi,
	I fully agree with Itojun's draft on generating the flow label within the network code. But
	I see no reason, why it should not be (at least) readable from application layer and why
	a single UDP or TCP session  should not handle more than one streams.

	Regards, 
	Jochen

	Hi. 

	I absolurely agree that it is very useful for the network to be informed that all the packets of a particular stream belong to a flow that should be treated similarly (like going along the same path).  Clearly the effects of the proposals in your draft and Itojun's draft at the network level are similar but the network code can do a much better job of generating the pseudo-random numbers needed to identify the streams (otherwise you need coordination between applications) and it reduces the temptation to use the flow label for application layer stuff which is the case when your proposal is followed.

	Regards, 
	Elwyn 

	-----Original Message----- 
	From:   Metzler Jochen [SMTP:[email-masked]] 
	Sent:   Wednesday, November 29, 2000 2:39 PM 
	To:     Davies, Elwyn [HAL02:HG00:EXCH] 
	Cc:     [email-masked]' 
	Subject:        WG: Usage of IPv6 flow label 

	1.  draft-metzler-ipv6-flowlabel-00 - the mechanisms proposed in this draft are not something that we should be supporting - it proposes polluting a network layer header with application layer info.  If an application needs to multiplex streams onto a single socket in the way proposed it could equally well format the PDU in an appropriate way without layer pollution.

	you missed the thing that it is not the intention of that draft to pollute the 
	network layer with application layer information. you are right in a way 
	that an application can / should handle multiplexing of streams internally. but 
	imagine that applications that request a special handling by the network 
	for every single stream, especially wanting all packets belonging to one 
	single stream to take the same way through the network. in that case 
	the application must signal the network which packets belong to which 
	flow. the flow label would be the right place for doing this, there would 
	be no mixture of network layers. 
	as shown by some other protocols (e.g. HC) it is legitimate  to use lower 
	layer information on upper layer protocols. if it is e-t-e or mutable a fully 
	standardized flow label would help in both cases application and network 
	design. 

	best regards 
	jochen 
	
--------------------------------------------------------------------
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: Thu, 30 Nov 2000 19:33:25 +0900

>a single UDP or TCP session  should not handle more than one streams.

	I admit there could be people who wants to use:
	- multiple flows (= multiple flow label value) in a single TCP session
	- multiple TCP sessions with single flow label value

	however, I could not find a good (a simple and usable) UNIX API to make 
	the above option happen, so I simplified the story.
	At least, the latter case can easily be handled by "single TCP session
	per single flow label".

	I documented the issue in section 5 of my draft.

itojun

---

From: [email-masked] (Niels M�ller)
Date: 30 Nov 2000 21:00:43 +0100

> 	- multiple flows (= multiple flow label value) in a single TCP session

That doesn't make much sense to me. A TCP connection is by definition
a single flow (or two, if you count directions). Hmm. Or more
precisely, it doesn't make sense to switch back and forth between
several flow-labels on the same tcp connection, but it might make
sense to switch to a _new_ flow-label.

Then one views the connection as a sequence of different flows, but
*not* as several flows that are in some way parallell or independent.

> 	- multiple TCP sessions with single flow label value

That makes sense, even if I have no idea if it is actually useful.

> 	At least, the latter case can easily be handled by "single TCP session

What about associating a flow-label with each open socket (which is
used for all outgoing packets), and supporting these three operations:

1. Make up a new, unique, flow-label and associate it with the given
   socket. 

2. Copy the flow-label association from one socket to another.

3. Reset the flow-label for a socket to zero.

I think you could do each of those as a ioctl or setsockopt or
something.

This way, applications never see the actual flow-label values, and the
network code always knows which flow-labels are in use and which are
dead.

/Niels

---

From: Dave Marquardt <[email-masked]>
Date: Thu, 30 Nov 2000 14:21:52 -0600

> 3. Reset the flow-label for a socket to zero.

I can think of a couple of others:

4. Retrieve the flow label from a socket.

5. Set the flow label on a socket to a specific value.

These together should allow UDP servers to associate flow labels with
particular traffic.  When such an application wanted to create a new
flow F, it would use 1 and 4.  When it sent packets to another
existing flow G, it could use 5.  When the application resumed sending
packets to flow F, it would again use 5.

-Dave

---

From: [email-masked] (Niels M�ller)
Date: 30 Nov 2000 21:43:18 +0100

> 5. Set the flow label on a socket to a specific value.

The problem with (5), I think, is that it makes it really difficult for
the networking code to know when a flow-label is no longer used, so
that it can be reused safely during (1) processing. 

> particular traffic.

You *can* do the same thing with only 1-3. Whenever you want to copy a
flow-label and use it later, you create a new socket, use (2) to save
the flow-label you are interested in, and you can use (2) to restore
it again later.

If you allow (5), if I can somehow discover the flow-labels used by
other users' processes (by magic or by passive sniffing of some
intermediate cable or something), then I can use (5) to assign the
same flow-label to my own sockets and cause trouble by violating any
requirements on flow-label use that the other user's processes and
friendly routers try to enforce. Is that a problem worth worrying
about?

Not doing (5) helps the network code to stay in full control of the
flow-label allocation; there would be no way to collide with the
flow-labels allocated to unrelated processes, neither by mistake or by
malice.

/Niels