Lines Matching refs:priority
62 As per [RFC 9000 2.3 Stream Prioritization], streams should contain a priority
69 void SSL_set_priority(SSL *stream, uint32_t priority);
73 For protocols where priority is not meaningful, the set function is a noop and
332 The frame types listed above are reordered below in the order of priority with
333 which we want to serialize them. We discuss the motivations for this priority
334 ordering below. Items without a line between them have the same priority.
361 ============================ ] priority group, repeats per stream
381 - `PADDING`: For obvious reasons, this frame type is the lowest priority. We only
410 frames. It is therefore trivially given the highest priority.
416 packets with high priority and due to their small size and the fact that there
439 consider them low priority, higher only than `PING` and `PADDING` frames.
440 Moreover, we give priority to control frames as unlike `STREAM` frames, they
458 higher priority than both `STREAM` frames and the stream-level flow control
463 priority.
466 are small and are given a high priority.
471 similar to application streams but of a higher priority. We are willing to let
480 frames are important to connection maintenance and thus are given a priority
482 priority than `NEW_TOKEN`.
486 to be transmitted. Thus `ACK` frames are given a fairly high priority;
487 specifically, their priority is higher than all frames which have the
492 This ensures that the high priority of the ACK frame does not starve the
566 in a fixed priority order; i.e., first there could be a `STOP_SENDING` frame
