- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Wed, 15 Jan 2014 09:43:52 -0800
- To: William Chan (陈智昌) <willchan@chromium.org>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 14 January 2014 17:22, William Chan (陈智昌) <willchan@chromium.org> wrote: > Timers are only necessary if you'd like to garbage collect. Otherwise, > what are you doing on a timer? So what you are saying is that if you don't want to do priority properly, you can ignore this END_STREAM_ACK message. That sounds reasonable I guess. I'll note that those implementations will lose any sanity checking on the message, such that a peer can send 0, 1, or many instances of the message and it will be ignored (though it might trip DoS counters). >> I don't think that you need the ORDERED bit. It seems to me like you >> could do "A <- B -- C" just as easily by having C reference A. The >> single chain of antecedent-dependent nodes is something an >> implementation could easily do, even if this were the case. I don't >> see the advantage to having ORDERED in the protocol. > > Having C reference A brings us back to dependency trees instead of > lists. Not really. If you send A <- B followed by A <- C, then that collapses to A <- B -- C. You can do that based on the order that the priorities are set (or by stream identifier numbers, but that would be harder to work out). > And if you have a D which is lower priority than both B & C in > your example, how do you express it? Depends. The easiest way is to require that D depend on the last stream in the priority class (i.e., D depends on C), which would be exactly equivalent to what your draft says. You could equally stipulate that the first in the group is identified (D depends on B). At the same time, it is possible (though less easy in practice due to the need for a little searching) to allow D to depend on either B or C. No matter what the choice, it's trivial to have the receiver translate that into A <- B -- C <- D. > Maybe you have D depend on B? And > if you have an E, what happens if you mark E as depending on C? What's > the priority ordering between D and E, if any? Again, if you stipulate a strict requirement to depend on the last (prioritized) stream in the group of equivalent ordering dependencies, then E would depend on C and produce A <- B -- C <- D -- E. > Once you open it up to a possible tree, it gets more complicated. In > terms of the complexity tradeoff, I think adding a bit for order is > simpler than having to have peers/siblings. It's not really a tree in the sense that you think. It's a list of lists. The exact same structure you describe in the draft in fact. See: A ^ B -- C ^ D -- E The only difference is that in the draft you make statements about what implementations do with their internal data structures, which isn't really necessary. >> If each stream has two priority-related properties, why not make them >> separate properties? It's fairly obvious that an ORDERED dependency >> doesn't require it, but an unORDERED dependency can have two numbers: >> the stream ID of its parent, and a relative weight compared to its >> peers. Then all streams would have both values, with streams >> inheriting a parent of 0 by default. It's a framing change, but I >> don't see why you couldn't add two numbers to each stream. > > OIC, this is something we didn't clean up. We don't want > siblings/peers. Just a single list. That's an implementation choice. Fact is, your nodes have two numbers on each. Why not make that explicit?
Received on Wednesday, 15 January 2014 17:44:20 UTC