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

[Brian E Carpenter <[e-mail]>]

On 2011-04-07 08:22, Scott Brim wrote:
> On Wed, Apr 6, 2011 at 14:49, Thomas Narten <[e-mail]> wrote:
> 
>> 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?)
>>
> 
> Last sentence first: Yes and the text that was there was
> 
>   "A flow is a sequence of packets sent from a particular source to a
>   particular unicast, anycast, or multicast destination that a node
>   desires to label as a flow."
> 
> ... but what the network should/should not do SHOULD be farther down in the
> draft where such things are already discussed, not in the (very small,
> simple) definition of a flow at the beginning, no?
> 
> But let's not spend a lot of time on it.
> 
> Completely agree on the rest.
> 
> 
>> 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.

We got a pretty clear message a few discussions ago to drop the
speculative text in RFC 3697 about how hosts would support the ability
of applications to do this. So the idea is to be silent on this.

   Brian