Re: [dispatch] Draft on Discarding Priority of RTP Video Packets

[[e-mail]]

I'm new to this, so please forgive me if I overlook something that is
well-known.  It does seem like the general idea is valuable, to be able
to prioritize packets for congestion discarding based on their value to
the underlying media encoding.  The limitations with using DSCP for
this are:

1) There aren't lot of DSCP values.
2) You don't want any single media stream to be reordered, and any set of
DSCP values larger than a single AFn group may be reordered.
3) Whereas you'd like to be able to mark packets with 8 levels of
discard priority.

So there is a conflict between the approach in
draft-dong-priority-rtp-packet (which uses a larger number of DSCPs but
which in the default environment could have reordering problems) and the
approach in RFC 8837 (which has only three discard priorities for a
single stream).

One question is whether making the information in
draft-ietf-avtext-framemarking visible to routers would be useful.  That
extension header contains rich information, of the sort that
draft-dong-priority-rtp-packet is concerned with, but to what degree can
a stateless packet forwarder take advantage of that?

If we want routers to be able to detect that extension header, it's not
obvious how to do it.  The extension header (if it is known to be the
first one) is located after only one variable-length header in the IP
payload.  But it's difficult to determine that a packet is an RTP
packet, as RTP has no clear signature.   By my count there are only 19
fixed-value bits in the packets we are concerned with.  It's also
impossible to determine whether an extension header is the framemarking
extension without observing the relevant signaling, since the extension
header IDs are assigned by the signaling.

One possibility would be to add before the framemarking header a fixed
value header whose only purpose is to provide a flag value that the next
header extension is framemarking.  We could arrange that the flag header
extension would have 32 fixed-value bits, which should reduce the number
of false-positive matches to make recognizing conformant RTP packets
practical.

Dale