Re: [Moq] New Version Notification for draft-lcurley-warp-02.txt

[Luke Curley <[e-mail]>]

Hey MoQ, this is the combined Warp + RUSH draft, with parts of
QUICR sprinkled in.

This base draft primarily focuses on how media is transferred over QUIC
streams. I spent extra time on the motivation, explaining how media
encoding works, and how we can utilize QUIC based on the encoding.

This is not a functional protocol at the moment as there's quite a bit of
bikeshedding to do. I've filed some issues
<https://github.com/kixelated/warp-draft/issues>:

   1. The name. I'm equally in favor of either WARP or RUSH.
   2. The wire encoding. Nothing is specified at the moment.
   3. The frame types. Right now there's just the bare minimum for media
   transfer.
   4. The fanout. I'm still not sure if we push (pub/sub) or attempt to
   pull (HTTP/3). These could even be separate drafts but I'd prefer to pick
   one.

I could also use some feedback from any media experts in the house. My
experience and terminology is mostly centered around H.264/AAC and HLS.

On Mon, Oct 24, 2022 at 3:47 PM <[e-mail]> wrote:

>
> A new version of I-D, draft-lcurley-warp-02.txt
> has been successfully submitted by Luke Curley and posted to the
> IETF repository.
>
> Name:           draft-lcurley-warp
> Revision:       02
> Title:          Warp - Segmented Live Media Transport
> Document date:  2022-10-24
> Group:          Individual Submission
> Pages:          24
> URL:            https://www.ietf.org/archive/id/draft-lcurley-warp-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-lcurley-warp/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-lcurley-warp
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-lcurley-warp-02
>
> Abstract:
>    This document defines the core behavior for Warp, a segmented live
>    media transport protocol over QUIC.  Media is split into segments
>    based on the underlying media encoding and transmitted independently
>    over QUIC streams.  QUIC streams are prioritized based on the
>    delivery order, allowing less important segments to be starved or
>    dropped during congestion.
>
>
>
>
> The IETF Secretariat
>
>
>