Subject: RE: Higher level question about flow label

From: Thomas Eklund <[email-masked]>
Date: Thu, 23 Aug 2001 11:26:37 +0200

Derek,

Basically I agree with your line of thinking. That the reason why I wanted a
"mpls" style flow where you would do traffic engineering on. But what is TE?
TE optimise and could also load balance the traffic in your network to
utilize the network as efficient as possible. So from a functional point of
view is very similar when you do load balancing across multiple paths
(composite links, ECMP etc).

I also saw Steve Blakes comment that is not recommended to use TCP/UDP ports
in the hash key for ECMP but the one of the biggest problem with the
bundling is to send one TCP flow over different path since it might end up
in packet re-ordering due the different delays etc and trigger TCP slow
start. To me it makes a lot of sense then to include the TCP/UDP ports when
you have your "hash key" since you would like that the same TCP flow take
the same path to not experience these problems.

One problem of course is maintaining per state flow info in the classifier
since it needs to be refreshed when the flow expires. It is also problematic
to update the CAM/SRAM in the forwarding plane with the flow info at
wirespeed. That is mostly handled by the control plane (or "slow path")to
update your flow tables (that sits in CAM/SRAM). But there I see that the
hop-by-hop option is very useful to signal "inband" or with the packet that
a new flow is going to be set up in the flow tables, since the first thing
you must check is that it is not next header 0 pointer and if it is you must
process that header.

-- thomas

>-----Original Message-----
>From: Derek Fawcus [mailto:[email-masked]]
>Sent: den 22 augusti 2001 19:47
>To: Brian E Carpenter; [email-masked]
>Cc: ipng
>Subject: Re: Higher level question about flow label
>
>
>On Thu, Aug 16, 2001 at 08:44:59AM -0500, Brian E Carpenter wrote:
>> I think the WG needs to decide once and for all whether the 
>flow label is
>>    a) a CATNIP or MPLS-like routing handle 
>> or b) a QOS hint for intserv only
>> or c) a QOS hint for intserv and diffserv
>> or d) a waste of bits
>> 
>> We can get back to the details once we have a consensus on this.
>
>I'd suggest e) A flow identifier for router optimisation.
>
>I sort of see this as a variation of b),  i.e. it identifies a 
>flow using
>a PRN but does not imply any QoS usage.  However it doesn't 
>preclude the
>flow label being used in scenario b).
>
>
>Specifically - I see it as a way of replacing the srcPort/dstPort tuple
>that routers peek at in the TCP/UDP header.  Currently I only see this
>being used in one scenario,  that is for load balancing across multiple
>paths.
>
>At the moment (for v4) if a lookup on the dst address address leads to
>a route with multiple paths,  and the route is appropriatly marked,
>the flows of packets can be shared across these multiple paths.  This
>is done (for min size IPv4 headers,  carrying TCP or UDP) by hashing 
>the srcIP/dstIP/srcPort/dstPort and using this to help choose which
>path to forward the packet over.
>
>Given that for IPv6 we can't guarentee the TCP/UDP header is at any
>given offset,  or even that it's readable.  One would need some other
>way of identifying flows if the above load balancing was to be 
>performed.
>
>For v6 a core router engine (either s/w path,  or ASIC [as fix logic
>or programable device as someone suggested]) one will not be looking
>beyond the base IPv6 header.  For an edge rouer engine,  one may well
>be looking inside the packet for say classification.
>
>Hence use the flowID.  Without this we could only hash based upon the
>srcIP/dstIP and hence all flows between a given src/dst pair will hit
>the same path.
>
>With this info in the flow label,  one would be able to hash together
>the srcIP/flowLabel to find the correct path.  As a router in this
>situation one would always have to combine the src IP address,  but
>if the flow label was defined to uniquely distinguish a given
>dstIP/srcPort/dstPort flow,  one could skip compining the dstIP at
>the router.
>
>The reason for specifying that it be a PRN is simply to make 
>the hashing
>cheaper at the router.
>
>I said above that this doesn't preclude using the flow label 
>for scenario
>b),  this can be achieved simply by picking a PRN for scenario b) from
>the same number pool as for scenario e).  Thus if intserv QoS is being
>used,  a (set of) routers would have been informed (via RSVP)
>about the relationship between that flow label and certain QoS
>requirements,  any other routers in the path of the packet flow that
>don't know about intserv/RSVP will simply treat packets in the flow as
>scenario e).
>
>So the usage becomes one that is (potentially) orthogonal to QoS.  It
>will be usable for non QoS'ed (intserv or diffserv) packets,  as well
>as with both intserv and diffserv.
>
>
>On Wed, Aug 22, 2001 at 11:41:30AM +0300, 
>[email-masked] wrote:
>> Earlier it has been thought that the pseudo-random nature of 
>the flow label
>> would make lookups easier by allowing the flow label to be 
>used as a hash as
>> such. There are some specific difficulties with this, however:
>> 
>> 1) Routers can not know how good pseudo random numbers the 
>flow-labels
>> injected by hosts are in practice. Bad pseudo random numbers 
>used by large
>> class of hosts could constitute a kind of DoS attack against router
>> implementations relying on the pseudo-random number nature 
>of the flow
>> label. [Maybe someone actually implementing look-ups on 
>hardware based on
>> the flow label could bring additional light on this matter (Alex?)]
>
>I'd disagree.  The router should only use the RPN in a 
>situation where a DoS
>can't occur.
>
>Take my example above - the route has already been looked up (using the
>dst IP address),  and we've got multiple paths.  We're now going to use
>the flow label to help pick the path.
>
>So say a set of originating hosts pick a poor PRN,  all that happens is
>that they end up getting less available bandwith for all of 
>their flows.
>This on the assumption that their choice of a poor PRN causes a sub set
>of the available paths to be picked.
>
>Note however that this doesn't affect other hosts with a good 
>PRNG which
>will be able to use more/all of the available paths.  It also doesn't
>mean that a DoS on any given path will occur - since queuing (say WRED)
>will occur after having picked a path.
>
>The only party hurt by their choice of a poor PRN is themselves.
>
>> 2) If there is an alternative format, that is not 
>pseudo-random (as being
>> proposed), the routers will have to implement look-ups that function
>> efficiently with that format. Since we do not know what 
>portion of the
>> traffic in the future would use this non-pseudo-random format, the
>> implementations have to assume that all traffic can be 
>labeled with this
>> alternative format.
>
>Lookups only occur when a QoS type funtion is applied to the 
>flow label,
>say we've been told about a flow by RSVP.  In this case a PRN 
>still helps
>since we can reduce the cost of lookups by hashing on the flow label to
>pick a subset of flows before doing a search/comparison.
>
>But then if the flow lable was a PRN,  we'd simply skip the 
>hash and use
>some of it's bits as a hash bucket index,  before jumping to the search
>and comparision phase.
>
>If QoS is not in use for that particular route & flow label,  
>then if the
>value was not random,  we'd have to use a more complex hash 
>algorithm in
>order to make sure we had got a good bucket distribution.
>
>DF
>
>--------------------------------------------------------------------
>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: Steve Blake <[email-masked]>
Date: Thu, 23 Aug 2001 10:54:51 -0400

> the same path to not experience these problems.

If you only hash on <srcaddr, dstaddr>, then all of the flows between the
two end-points will follow the same path.

There is a good paper by Cao, Wang, and Zegura analyzing the performance
of various hashing schemes at http://www.ieee-infocom.org/2000/papers/650.ps.

Regards,

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Steven L. Blake               <[email-masked]>
Ericsson IP Infrastructure                   919-472-9913