origin frame race condition (not the obvious one)

[mcmanus]

7540 has coalescing rules that are overruled by Origin frames - we all know that can't take effect until the origin frame(s) have been received at the client - so that's the basic race condition that we're comfortable with.

But because the origin set is done one origin in one frame at a time, and there is no End-of-Set marker on it, the set can become initialized before it is complete upon receipt of the first frame. Initialization means any origin that will soon be in the set but has not yet been processed will not be coalesced onto this connection even if it meets the rules of 7540.. that's the state that is intended at the end of origin set processing, but this interim state seems counterproductive.

The easiest thing to do seems to be to create some kind of checkpoint flag that means 'generation done for now'.

[mnot]

It's not one-origin-per-frame; it can contain many.

I think we've discussed this; both for Origin and Cache Digest. The problem is that if the COMPLETE (or whatever we call it) flag isn't set, how long does the client wait around for? We'd have to be very careful to make sure that the semantics are "more ORIGIN frames immediately following", rather than "wait around, I might have some more for you in a bit."

Given that an ORIGIN frame can convey quite a few origins (unless you've restricted maximum frame size) is this enough of an issue to justify the mechanism?

[martinthomson]

Hmm, without a COMPLETE signal, the client might not coalesce even if it could. That's suboptimal but it resolves fairly quickly once ORIGIN arrives. The client can interrupt an in-progress connection attempt and coalesce once it learns the new origin.

As @mnot observes, if you add a COMPLETE signal, the client can know that it might wait (by testing that the server is authenticated for the origin), but how long does it wait? I think that I would rather just fall back to the non-coalescing mode and interrupt if the ORIGIN frame arrives in time.

Note that in 1-RTT TLS 1.3 the server speaks first, so the race can be reduced somewhat.

[mcmanus]

multiples definitely help - I forgot to acknowledge that. But the general case is N frames.
I think this bothers me more than the base race condition of waiting for the ORIGIN frame to arrive, because it actually undoes 7540 quite accidentally.

imagine wanting to coalesce a set and having it setup via the usual DNS rules.. you want to also advertise that same set via origin to get the privacy and no-lookup wins.. halfway through you lose any coalescing for part of the set :(

not sure what the big deal with waiting is. That's state you're going to have anyhow - you're just not committing it yet.

[mnot]

I can see that we introduced something new with the DNS rule change -- now there's a point in time where the client has to decide whether or not to resolve DNS for a given origin.

[mnot]

So it sounds like what you really want is a flag that triggers the omit-DNS behaviour?

[mcmanus]

given a little time to let this issue breathe I think the right thing to do might be to just highlight the issue with a little text suggesting that frames should be atomic, which might lead folks to pack their frames rather than doing 1 per origin..

[mnot]

@mcmanus how's that?

[mcmanus]

sure. thanks