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.) [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. 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. Nit: what actually is 'dynamic flow state'? This is the only place where 'flow state' is qualified like this. Is that significant? > > Brian > Robert H. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
