I don't agree. My reasoning is that signals in the first 576 bytes are more likely to pass through non-conforming systems based on length alone. There is also John Scudder's observations on fast-path and slow-path processing: if its inside the state you latch EARLY when you see the packet, its far more likely to avoid CPU stalls and get done in firmware or hardware. (probably not strictly applicable, but I go to "flag early, flag often")
But, for other reasons raised by other people, I concur that these bits are excluded from use because we don't have time travel and middleboxes make false assumptions. -G On Thu, Jul 27, 2023 at 10:08 AM Robert Edmonds <edmo...@mycre.ws> wrote: > > George Michaelson wrote: > > if QDCOUNT is defined as [0|1] then we have 15 new bits of freedom in > > the header. > > > > What would be interesting uses of the flow-label? Oh wait.. that's > > right, nobody really knows at scale how to use flow-label either. > > > > I tend to "use it for 15 bits of signalling" because there are a lot > > of things I wish were signalled from client to server. > > > > "I am new code" > > "I am at least not ancient code" > > "I'm the same as that other guy you saw over <there>" > > "I like TCP and want to do a persisting session" > > "tell me if you are doing a|b|c|d" > > "I like chocolate and want a pony" > > > > maybe the truth is, we've got 15 bits of zero in the header forever, amen. > > > > (I deliberately didn't put this in the draft- post from Ray so as not > > to pollute an objective discussion of what it is or is not the value > > proposition) > > > > clue-stick hits welcome. Avoid the stomach. > > > > -G > > With a maximum length QNAME inside a UDP query packet there are slightly > under a couple thousand bits available for EDNS. Those bits at the end > of the packet are easier to get to, ecosystem-wise, so if those use > cases are worthwhile they should probably be done with EDNS. > > -- > Robert Edmonds _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
