Mark,
I was hoping someone else might chime in, but since they didn't, let
me extract from your messages:
> So those [IPFIX] timeouts are more to do with emission of flow records, and
> flow cache maintenance, rather than being a more general definition of
> what a flow is
Certainly. But supposing someone was led to build a stateful flow marker.
(That's on the assumption that we change the rules to allow routers to
overwrite the flow label.) A stateful marker would have exactly the same
problem with UDP flows as an IPFIX meter. By contrast, a source host
never has this problem, because it knows by construction when a flow
ends (chances are, flow == socket).
Brian
On 2010-04-19 09:41, Mark Smith wrote:
> Hi Brian,
>
> On Fri, 16 Apr 2010 11:50:28 +1200
> Brian E Carpenter <brian.e.carpen...@gmail.com> wrote:
>
>> Hi Mark,
>>
>>> Are you generally trying to avoid it because it would appear to be an
>>> implied IETF definition of a flow, rather than just the IPv6
>>> definition? Or is it to avoid having to start defining the a possibly
>>> large set of flow definitions?
>> Actually, because I have enough email to deal with right now anyway :-)
>>
>> Your proposed definition looks reasonable, but the IPFIX people have
>> a rather different definition:
>>
>> "A flow is defined as a set of IP packets passing an observation point
>> in the network during a certain time interval. All packets belonging
>> to a particular flow have a set of common properties....
>> A flow is considered to be expired if no packet of this flow has been
>> observed for a given timeout interval" [RFC3917]
>>
>> The crucial difference is the tiemout. In the observational world
>> of IPFIX, a flow is deemed to end when there is a certain period of
>> silence. So a stop-start flow meeting your definition might be
>> broken up into multiple flows by IPFIX. That's where things get vague.
>>
>
> My understanding is that IPFIX is generally an IETF standardised
> version of Cisco's Netflow. In Netflow, timeouts are needed for a
> few reasons:
>
> o A timeout is used to expire flows for protocols that aren't
> connection oriented (e.g. UDP) or the implementation doesn't know
> are connection oriented because the implementation doesn't understand
> the protocol. When the timeout occurs, a netflow record is emitted
> towards the netflow collector, and the router clears the netflow cache
> entry for the flow.
>
> o Long lived TCP connections may go for long enough that people want
> to know partial flow information about them. This timeout is an upper
> bound on how long a flow can continue before a netflow record is
> emitted. The TCP flow stays active in the flow cache, so there will be
> at least another netflow record at the end of the TCP connection or if
> the flow cache becomes full and the flow is punted from it.
>
> So those timeouts are more to do with emission of flow records, and
> flow cache maintenance, rather than being a more general definition of
> what a flow is.
>
> Regards,
> Mark.
>
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
