Margaret Wasserman wrote: > You have given one single example (the congestion discard > case), where an ambiguous flow label might have some > limited usefulness.
You asked for an example, and that was the one that came to mind without any significant study. > [Have you analyzed how this compares > to other congestion management techniques, BTW?] Not in any detail, I considered it to be a simple example of how one might augment some of the existing congestion techniques. > However, in order to get this limited usefulness, we would > need to place constraints on all possible IPv6 flow management > systems that would use the flow label (specifically, that it > would be e2e, and that the same value would infrequently > be used between the same src/dst pair, such as in the > random case.). > > You have not demonstrated (or even tried to argue) why this > one congestion control technique would warrant placing these > restrictions on all IPv6 flow management mechanisms. I clearly have not demonstrated it to your satisfaction, but I have argued that architecturally we need both a mutable and an e2e immutable field to address different parts of the problem space, and specifically that the only point with the knowledge to associate packets as a flow is the origin application/host. Conversely, those arguing against locking it down have not demonstrated why the mutability of the DSCP is insufficient for any conceivable scenario where mutability is required. Specifically what would be the purpose in having 2 fields that are modified by the routers? Why wouldn't the existing DSCP be capable of expressing different semantics through different bit patterns? How does adding a separate 20 bits make that any different? If we are simply arguing about who gets to decide, then I believe the IPv6 WG is the responsible entity for defining the architectural behavior of the header fields. As such I return to the base issue, at least one field needs to be end-to-end immutable, and the only one available is the FL. This of course works well since the origin node is the only one who could properly define a flow anyway. Tony -------------------------------------------------------------------- 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] --------------------------------------------------------------------
