Re: 6MAN WG Last Call: <draft-ietf-6man-flow-3697bis-02.txt>

[Thomas Narten <[e-mail]>]

Hi Scott.

Scott Brim <[e-mail]> writes:

> >    A Flow is a sequence of packets originating from a particular
> >    application that should be treated "the same" by the network as
> >    they are forwarded along to their ultimate destination. Packets
> >    within a flow should not be reordered, should not be given
> >    dissimilar QOS treatment, etc. What constitutes a Flow can only be
> >    defined by the application itself.
> >

> Sorry, Thomas, I don't think this will work.  First, I don't think we can
> define a "flow" by what the network should do with it, whatever it
> is.

Well, we are defining a flow by what the network SHOULD NOT do with
packets belonging to the same flow. I.e., packets within a Flow should
not be reordered. That seems to be the key requirement/principle. (Are
there other attributes?)

> If something is definable, then it has attributes independent of how
> other things behave toward it.  It seems that a flow is anything the
> node labels with the same flow label.

Right.

> If so (as in your last sentence), then that's the only definition
> you have.  Also, a flow doesn't necessarily originate from a single
> application.  It could be multiple.

Agreed.

> Some environments don't even have applications.  My inclination
> would be to decline this definition change.

What I think is worth highlighting is that what constitutes a flow can
only be defined by the source of the traffic (i.e., the application(s)
or whatever is at the higher layer). The source node may be using
heuristics to label flows that don't completely match up with what the
application thinks.  That is not necessarily a problem (it's reality),
but I think its useful to make that distinction.

I.e., ideally, the higher layers are what label individual flows. But
if that doesn't happen, the sending node can use heuristics (like
looking at port numbers to fill in the Flow Label) and do pretty well.

Thomas