One of the coauthors agrees with you about the need for a defined timer. But I was talked out of it. Let's hear what the WG thinks about this.
Brian Robert Elz wrote: > > This doc is mostly OK, but if it is going to specify that the > flow label be unique (within the source/dest addr space), it also > needs to specify for how long that needs to remain true. > > Comparisons with TCP ISN's have been made, and that's fine - but > with TCP, the period within which an ISN should not be reused is > known - one technique a TCP implementation can use, other than > stable storage (or other ways) is simply to abstain from using > any ISNs (that is, from sending packets) for a set period after > a restart. > > While that's hard for TCP, and so few implementations these days > actually force the node to remain silent for minutes after a restart, > with flow labels, the existence of the 0 value, mitigates this, > and would allow a node to simply not use flow labels for a period > after a restart. But only if we have some idea what that period > is to be. > > There has to be a period, or after 2^20 - 1 flows between a source and > a destination, there could never be another. > > The period needs to be explicit (either a constant, or algorithmically > derivable). Stacks need to know what it is, and routers need to have > some guidance on how long idle state might usefully be retained (without > constraining them, beyond what the flow setup protocol does, to actually > do anything at all with flows). > > When we get to APIs (the other issue discussed here recently), I > suspect that we're going to need a mechanism to set a specific value > as the flow label (and the application would be resonsible for > ensuring it was valid to use), a mechanism to simply set a new flow > label, without caring about its value (in which case the stack would > apply the uniqueness constraint - which might then mean dividing the > flow label space (for that stack) into some available for apps to > set, and some for the kernel, or the bookkeeping would get real hard), > and a mechanism to set no flow label. This can't be directly died to > sockets, as multiple of those might want to be using the same label > (though one way to do that would be to have a label picked, then a method > to obtain the value selected, then force that into the other sockets). > Nor can it be tied to bind/connect sys calls - the lifetime of a label > and the lifetime of a TCP connection (or the thing which UDP gets when > connect is used) aren't necessarily related. Using those to supply > default labels, when there is no other app request, would mean mods to > less applications though. > > kre -------------------------------------------------------------------- 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] --------------------------------------------------------------------
