Re: [Wish] WISH re-charter

[Bernard Aboba <[e-mail]>]

Tim said: 

“ > How about adding some wording that the group may investigate using
> DataChannels to support some use cases.
> I don’t think we know enough yet to be more specific (and it is a charter
> not an RFC) but it seems clear to me that there are some use cases where 
> the data channel could play a useful role.”

[BA] “May investigate” is too wishy-washy.  The WISH WG needs to produce a requirements document that defines the necessary functionality and can be used to determine when the work is “done”.   The requirements document doesn’t have to very long or be exhaustive (it’s not an applicability statement).  It just has to clearly identify the feature set needed to satisfy a core set of customers.  In the process, WISH will also clearly differentiate itself from other IETF efforts such as MoQ. 

The reason this is so important is that existing IETF WGs that were allegedly focused on streaming skipped the “requirements” stage and now after years of work have discovered major gaps in functionality that some claim make them unsuitable for their stated purpose.   Had the use case work been done, those arguments would have occurred early on, when they could have influenced the design.  Now we have people in MoQ claiming WebTransport’s lack of support for P2P operation (something supported in WHIP and WHEP) is a problem for distribution, and the W3C WebTransport WG realizing that the protocol can’t handle low latency ingestion with the congestion control (BBR, New Reno) shipping in existing implementations.

WHIP and WHEP have the potential to address the use cases that now appear out of reach for the IETF’s other streaming efforts.