Subject: RE: [NSIS] IPv6 Flow Label

From: "Hancock, Robert" <[email-masked]>
Date: Thu, 11 Jul 2002 15:46:24 +0100

Hi Sarantis,

see inline:

> -----Original Message-----
> From: Sarantis Paskalis [mailto:[email-masked]]
> Sent: 11 July 2002 12:59
> To: Hancock, Robert
> Cc: [email-masked]; [email-masked]
> Subject: Re: [NSIS] IPv6 Flow Label
> 
> 
> Hi,
> 
> On Thu, Jul 11, 2002 at 12:04:21AM +0100, Hancock, Robert wrote:
> > John,
> > 
> > Interesting draft. I have tried to think it through from a 
> purely NSIS perspective.
> > 
> > 1) Nowhere does it say if routers (or even sources) should 
> send packets from the same flow along the same path. Is that 
> because it's (a) the wrong place to say so or (b) obvious or 
> (c) impossible to mandate? In particular, it does say that a 
> node not carrying out flow specific treatment MUST ignore the 
> field on forwarding - maybe 'keeping packets together' could 
> be regarded as flow specific treatment (and made mandatory). 
> (If we could rely on this it would be a powerful weapon in 
> the signalling/data path divergence issue, but see next point.)
> 
> The only thing relevant mentioned in the draft is a sentence 
> in Section 2
> 
>                                                 The flow state defines
>    what kind of treatment should be provided, and how to classify the
>    packets to the flow.
> 
> According to that definition, NSIS could define the state of 
> the flows to
> always follow the same path.  The second part of the sentence 
> also applies
> to point 2.
[reh] the problem is that if the packets of a flow do not follow a unique path, saying the state of the flow always follows 'the' path is not meaningful. in any case, it's not an NSIS responsibility to define how routers do load sharing (for example). (or, I don't understand your point.)

> 
> > 2) The draft seems to encourage (SHOULD) a highly granular 
> assignment of flow labels (e.g. section 4 rules 3 & 4). On 
> the other hand, there may be good reasons to use the same 
> label for a sequence of 'microflows' (e.g. successive files 
> in a bulk ftp transfer; the same point has been made on the 
> v6 list). Encouraging this granularity directly increases the 
> signalling burden. How strong is SHOULD?
> 
> I think, this is partially covered in Section 5, rule 1.  
>    
>        Depending on the method semantics, multiple such triplets MAY
>        identify the same flow state (e.g. SCTP flows with multiple
>        addresses at either end-points, or a diffserv 
> classifier with an
>        address range.
> 
> This can be extended to cover the case for a "flowmask" in 
> which the first
> say 15 bits identify the flow state, while the last 5 identify the
> "microflow".
[reh] that's a very natural idea. on the other hand, it can't be defined on a case by case basis, since that section is about allowing multiple (including presently unknown) flow state establishment methods to co-exist. if you think co-existence is important, any such flowmask method would (I think) need to be defined in this draft (which is probably overkill).

i don't think there's an easy answer to this question.

> 
> In that case the draft states that:
> 
>                           The flow state establishment method MUST
>         convey this classifying information to the IPv6 nodes 
> that need
>         to perform the classification.
> 
> i.e. this should be a NSIS requirement.
[reh] that is clear.

> Cheers,
> 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: Fri, 12 Jul 2002 13:21:40 +0300

> [reh] the problem is that if the packets of a flow do not follow a unique path, saying the state of the flow always follows 'the' path is not meaningful. in any case, it's not an NSIS responsibilit…

Yes, I was not clear.  What I meant was that NSIS would define the flow
specific treatment at the intermediate router to include forwarding the
packets of a flow to the same interface, i.e. to follow a "path".  I am
not sure if this can be an NSIS requirement or not (to always direct flow
specific traffic to the same interface if possible).

My understanding from reading the draft is that this responsibility
is left to the "flow state management", i.e. NSIS in our case.

> i don't think there's an easy answer to this question.

I think it can be defined on a case-by-case basis based on specific NSIS
signaling, i.e. an NSIS message defining the grouping of several flowlabels
into one logical flow.

By "flow state management methods" I thought something of NSIS, RSVP, etc.
In these cases, I don't see any interference between different flow state
management methods, if the flow label space of one is independent from the
flow label space of the other.  This is natural, since the application
(or any other entity) initiating a flow (possibly of multiple microflows)
will choose to signal its requirements by only one signaling protocol.
The flow labels will be unique for that source address, so the flow state
management at intermediate routers will not have to deal with multiple flow
state management methods dealing with the same flow.

> > i.e. this should be a NSIS requirement.

There is a conflict with draft-ietf-nsis-req-03.txt, section 5.5.5 (possibly
only naming conflict).  In the flow-label draft, several microflows with
different flow labels are treated as one flow, whereas in the the nsis-req
draft, the microflows are treated as independent flows (and their
signaling is just grouped together for efficiency).

Regards,

-- Sarantis

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