below...
"Hancock, Robert" wrote:
>
> Dear all,
>
> A couple of comments on the 'router treatment' and 60s timeout issues:
>
> > > Note: what I would expect this draft to describe is:
> > >
> > > 1) what arbitrary source nodes should do with the flow label.
> > > 2) what routers should do with the flow label.
> > >
> > > The document appears to do 1), but 2) is omitted from the
> > document. Is
> > > this OK?
> >
> > IMHO, it's not only OK, it is essential at this stage. There
> > are a number
> > of use cases for the flow label - if I even enumerated them here, they
> > are controversial enough to start a flame war. The draft has been very
> > carefully limited to *avoid* assuming any particular use
> > case. It serves
> > two purposes, in my view:
> > -- setting globally applicable boundary conditions on what a sending
> > host may and may not do;
> > -- making it clear that intermediate systems may use the flow label
> > for packet classification purposes (which means, in particular,
> > that ASIC and network processor designers know that they should
> > include the flow label in the fields potentially used by
> > classifiers).
> > Going beyond this point would take us back into the controversy we
> > had on this list a year or so ago. So, to repeat, it would *not*
> > be OK to attempt to specify what routers should do with the flow
> > label.
>
> I sympathise with Brian's caution, but I'd still like to probe if
> there is any non-controversial guidance that can be given about routers
> treating packets within a single flow somehow "consistently"
> (e.g. keeping to the same outgoing interface in the absence of
> re-routing, avoiding re-ordering and so on). This would be a default
> in the absence of any specific flow state establishment mechanism.
> (This type of thing is slightly discussed in 1812, so maybe it's
> more of a node requirements topic. I agree there are additional
> subtleties to be considered.)
Right, is there anything we can say that isn't "obvious" in
terms of generic router requirements? Send text!
>
> [snip]
> > >
> > > > Nodes keeping dynamic flow state MUST NOT assume
> > packets arriving 60
> > > > seconds or more after the previous packet of a flow
> > still belong to
> > > > the same flow, unless a flow state establishment method in use
> > > > defines a longer flow state lifetime or the flow state has been
> > > > explicitly refreshed within the lifetime duration.
> > >
> > > I'm not entirely comfortable with the above wording. It seems to me,
> > > that any node making assumptions about flow values *needs* a flow
> > > setup mechanism to go along with it. But if there is such a
> > mechanism,
> > > that mechanism can communicate appropriate timer values for
> > timing out
> > > state (and the above words are not needed). If there is no such
> > > mechanism, what sort of flow-specific processing should
> > assume that a
> > > gap of 60 seconds implies a reset in the flow?
> >
> > We don't know, and 60 seconds is a compromise value anyway. But there
> > seemed to be WG consensus that a default timeout is needed, since
> > otherwise we are licensing implementors to create hard state.
> > The authors
> > have been round and round this many times, and this was the best we
> > could come up with. (more comment on this below)
>
> I agree with Thomas' reasoning, i.e. I can't see under what circumstances
> these words wouldn't be superseded by ones specific to a specific real
> FSEM. (In particular, they don't prevent an FSEM mandating hard state
> itself anyway.) On the same grounds, I suppose I shouldn't object to the
> words too strongly either.
Exactly, they are apparently harmless and they might prevent some
implementor from doing something stupid (like creating hard state).
>
> However, the wording in terms of inter-packet gaps seems to imply an
> expectation of implicit flow state refresh, i.e. that flow state will
> persist while packets continue to flow, and that a flow-aware forwarding
> engine must be able to support updating a per-flow timer for each packet
> it forwards. Can this really be the intention? Or have I just confused myself?
>
> If we really must have this, how about something like
>
> Nodes keeping dynamic flow state MUST flush it after 60 seconds,
> unless it is maintained by whatever refresh method is associated with the
> corresponding flow state establishment mechanism, whose specification may also
> redefine the 60 second default flow lifetime.
Something like that would be fine for me.
>
> Nit: what actually is 'dynamic flow state'? This is the only place where 'flow
>state' is qualified like this. Is that significant?
I think 'dynamic' is a noise word. Again, the concern was to avoid
hard state, but the word can be deleted.
Brian
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
