Subject: RE: Usage of IPv6 flow label

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Thu, 16 Nov 2000 09:45:22 +1100

> >> >- Can intermediate routers change the flow label?
> >> >  Appendix A of RFC2460 states that hosts or routers that
> >> >  do not support the flow label should pass the field on 
> >> >  unchanged. Is this also true for hosts or routers that
> >> >  do support the flow label? What is the procedure if an
> >> >  router supports flow labels but has no context about a
> >> >  specific flow label? 
> >> 	seems to me, no.
> >	=> Agreed. Also based on my comment above I 
> >	don't think it would be a good idea. 
> >	I can't remember if it's included in the AH calculation 
> >	or not. 
> 
> 	flow label field is not part of AH calculation, but as RSVP already
> 	requires it to be end-to-end (not hop-by-hop) i think we shouldn't
> 	rewrite it in transit.
> 
	=> Agreed.
--------------------------------------------------------------------
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: "Thomas Eklund" <[email-masked]>
Date: Thu, 16 Nov 2000 13:51:51 +0100

Note my comment was NOT bound to either diffserv or intserv.

It was a discusson on the IP header structure and things that might become
an issue when v6 gets more deployed (which means it will run in both asic's
and np's as well). My suggestion was an issue that is related to determinism
to achieche QoS but the same classification mechanism is used in packet
filterering firewalls (that might alsoi have a counter associated - i.e
stateful inspection) as well. This problems arise from existing memory
contraints (and at least future constraints within 2-3 years from now).

But it was a question/issue raised from me if people shared my concerns.

-- thomas

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Francis Dupont
> Sent: den 16 november 2000 13:25
> To: Metzler Jochen
> Cc: Jun-ichiro itojun Hagino; Hesham Soliman (EPA); Ipng (E-Mail)
> Subject: Re: AW: Usage of IPv6 flow label
>
>
>  In your previous mail you wrote:
>
>    Can you explain to me what the matter with DiffServ is?
>    I assumed that DiffServ makes use of the ToS field and
>    not of the flow label?
>
> => a part of this comes from a collision with a discussion initiated
> by Thomas Eklund about DSCP and flow label marking...
> The notion of edge routers is in the DiffServ architecture not in
> the IntServ/RSVP one, and the same for the idea to mark packets
> by edge routers and to use marks on core routers, but of course
> these ideas can be (and are) used by RSVP too.
>
> [email-masked]

---

From: Metzler Jochen <[email-masked]>
Date: Fri, 17 Nov 2000 14:23:24 +0100

some words for clarification, regarding the flow label within 3GPP:

as far as I know is the flow label ONLY part of the Packet Filter Attributes,
which are used to classify User Packets (- from an 3GPP point of view -)
to distinguish between several connection of a certain user. It is only an
optional criteria in the case of IPv6 User IP. (see 3GPP TS26.060)
 -- jochen

	-----Ursprüngliche Nachricht-----
	Von:	Hesham Soliman (EPA) [SMTP:[email-masked]]
	Gesendet am:	Freitag, 17. November 2000 13:27
	An:	'Michael Thomas'
	Cc:	'Ipng (E-Mail) '
	Betreff:	RE: Usage of IPv6 flow label 

	> Hesham Soliman (EPA) writes:
	>  >  > >    Er, by what protocol does it inform the router?
	>  >  > > 
	>  >  > 	=> A 3GPP protocol. 
	>  > 
	>  >    Which is different from an IETF protocol?
	>  > 
	>  > => Yes. Otherwise it would not be a 3GPP protocol ;)
	> 
	>   Is there some compelling reason why RSVP is not
	>   that protocol, or is this yet another case of
	>   the parochial "our layer 2 is _so_ different we
	>   can't possibly use widely accepted and standards
	>   based protocols."
	> 
		=> You have to ask someone from 3GPP who worked
		on that protocol. There are some reasons for their
		chioces, whether you agree with it or not it's a different 
		story. You can get more detail if you ask the people 
		who invented these protocols. Anyway this is getting 
		outside this mailing list's interest.

		Hesham

---

From: "Thomas Eklund" <[email-masked]>
Date: Wed, 22 Nov 2000 11:07:07 +0100

Hi Jim,

> Because the diff serv bits are too precious rather take one
> from 20 than
> the few left in tos/class.  But I am not convinced this is the correct
> technical answer but might be the only answer.  I got at least 4
> different inputs in the customer base for four different uses of the
> flowlabel.  But the good news is the needs all aggregate to I hope two
> solutions we are discussing now.

I still dont understand what the ECN bits have to do with the flowlabel, and
as I said the most way of using the ecn bits have been in the 2 unassigned
bits in the TC field, which makes sense because the DSCP are 6 bits and that
leaves the room to use the remaining two bits in that field..

This clearly shows that there is time now for standadizing the flow label
field and semantics so we dont have XXX different ways of using it.

> Think I answered above on why not the tos/class field.

Sorry - i did not understand your concerns here..

-- thomas

---

From: "Elwyn Davies" <[email-masked]>
Date: Wed, 29 Nov 2000 17:59:16 -0000

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

> 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