Subject: RE: [NSIS] IPv6 Flow Label

From: "Hancock, Robert" <[email-masked]>
Date: Mon, 15 Jul 2002 16:17:51 +0100

hi Sarantis,

[for others still following - I think the upshot of this thread is that there is clearly another issue, about section 5 rule (1):
*) it's ambiguously written
*) on one interpretation, it contradicts NSIS requirements.]

[snip]
> > [reh] the issue here is when the person managing the flow 
> label space might not be the same person doing the 
> signalling. The draft mentions one case (signalling initiated 
> by flow receiver, penultimate paragraph of section 2), we are 
> also interested in cases where the signalling could be 
> initiated by intermediate nodes.
> 
> The entity doing the signaling is responsible for the flow label(s)
> classification.
> 
> In those cases, where the signaling is initiated by 
> intermediate nodes,
> flows can either be identified by some preconfigured 
> templates or through
> heuristics.  In either case, the intermediate node initiating 
> the signaling 
> is responsible for the flow grouping and the "flow classification" 
> information forwarding.

[reh] right - so if those flow labels are allocated in this highly granular way and/or highly randomly, by a source which knows nothing about this signalling, these classification rules will be more complex (which was the original point).

> 
> > [reh] There are two points here:
> > 1) Rule (1) of section 5 seems ambiguous: does the flow 
> state establishment method have to convey the grouping of 
> triplets, or just the state in each triplet. In other words, 
> does 'this classifying information' refer to just the first 
> sentence in the rule, or the second as well.
> > 2) If it does refer to both, I don't believe the 
> requirement is enforceable (after all, packets for different 
> triplets might follow different paths, and the idea of the 
> same state for each probably isn't even meaningful - which is 
> why the NSIS requirement is restricted the way it is). If it 
> doesn't, there is no conflict.
> 
> My understanding is that it refers to both.

[reh] ok this needs to be clarified.

> The argument about different
> path for packets with different triplets could apply to packets of the
> same triplet following different path (eg. due to load balancing).

[reh] true, the point of the original question (1) was whether this was trying to be ruled out at least for the single triplet case.

> 
> I think there are two orthogonal management problems.  One is the flow
> _state_ management in each node, i.e policy, QoS enforcement, 
> etc.  The
> other is the flow label space management.  The problem we are 
> looking at
> is the latter.  More specifically, I think we are looking at the
> possibility of propagating the logical grouping of several microflows
> that should be treated as one flow.  Something like RSVP 
> Wildcard filter,
> applied to flow labels.

[reh] i think doing this at the triplet level where there is diverse routing (remember, they may all have different destination addresses) will be a huge source of complexity. is it really worth it? otherwise we are just talking about flow grouping as already in NSIS.

> > Robert H.
> -- Sarantis
========================================================================================
Permission is hereby granted to pass the contents of this communication to third parties and any restrictions regarding confidentiality do not apply.

---

From: Sarantis Paskalis <[email-masked]>
Date: Wed, 17 Jul 2002 16:41:30 +0300

Hi Robert,

> *) on one interpretation, it contradicts NSIS requirements.]

Correct.

> [reh] right - so if those flow labels are allocated in this highly granular way and/or highly randomly, by a source which knows nothing about this signalling, these classification rules will be mor…

If the signaling is initiated at some intermediate nodes, it would be
indeed a very difficult task to group different triplets together to one
state.  Especially since the intermediate node has no information about
how the flow labels should be grouped.  In that case, heuristics obviously
fail.  Other possible scenarios would be to ignore the flow label and only
take into accound source and destination address fields for grouping
purposes or hardcode the necessary values to the signaling initiating node.
In either case, the signaling initiating node has no information about 
the flow label to actual flow correspondence.  Any action it performs is
an effort to guess the flow initiator's intentions, and that is also
valid for single triplet flows.

If the signaling is initiated at the endpoints, however, there are some
obvious benefits from flow label distribution and signaling interworking.

> [reh] i think doing this at the triplet level where there is diverse routing (remember, they may all have different destination addresses) will be a huge source of complexity. is it really worth it…

How can flow labels denoting the same flow have different destination
addresses?  I thought we were talking about same source and destination
addresses, but different flow labels for the same flow.  In case of different
destination address, we have different flows by definition.

If you meant diverse routing for different triplets (i.e. different flow
labels), there could always be diverse routing for the same triplet.  In
other words, the problem space of the flows with the same triplet is the
same as the one of the flows with different triplets.

-- Sarantis

--

_______________________________________________
nsis mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nsis