Re: [AVTCORE] [Wish] Video ingest over QUIC

["Das, Dibakar" <[e-mail]>]

Thanks. So, you are making use of Stream ID being pretty long and there is no chance of overflow.

From: Kirill Pugin <[e-mail]>
Sent: Friday, July 23, 2021 11:16 AM
To: Das, Dibakar <[e-mail]>; Alan Frindell <afrind=[e-mail]>; Sergio Garcia Murillo <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Wish] Video ingest over QUIC

1 stream 1 frame

From: "Das, Dibakar" <[e-mail]<mailto:[e-mail]>>
Date: Friday, July 23, 2021 at 11:07 AM
To: Alan Frindell <afrind=[e-mail]<mailto:afrind=[e-mail]>>, Sergio Garcia Murillo <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Kirill Pugin <[e-mail]<mailto:[e-mail]>>
Subject: RE: [Wish] Video ingest over QUIC

Hi Alan,

Thanks for sharing the document. I had a minor clarification question on the following text:



“Connection establishment follows the normal procedure by client sending Connect frame, after that Video and Audio frames are sent using following rules:

·       Each new frame is sent on new bidirectional QUIC stream

·       Frames within same track must have IDs that are monotonically increasing, such that ID(n) = ID(n-1) + 1”



Does this mean each QUIC stream is used for transmitting only 1 or 2 frames ?



Regards,

Dibakar


From: QUIC <[e-mail]<mailto:[e-mail]>> On Behalf Of Alan Frindell
Sent: Tuesday, July 13, 2021 12:02 PM
To: Sergio Garcia Murillo <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Kirill Pugin <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Wish] Video ingest over QUIC

Hi Sergio, thanks for your interest in the draft.

I’m interested in seeing a video ingest protocol standard that leverages QUIC as a transport, has some partial reliability support, and is less connection-oriented so that servers can go down for maintenance without impacting ingest reliability or having arbitrarily long drain times.  We published our RUSH draft to help kickstart the conversation but we’re open to feedback and modifications if they help advance those goals.

Thanks

-Alan

From: Sergio Garcia Murillo <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, July 13, 2021 at 9:02 AM
To: Alan Frindell <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Kirill Pugin <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Wish] Video ingest over QUIC

Hi Alan,

I think that the correct place for discussing it is AVTCORE as Bernard has indicated, as  WISH is not chartered to implement any new media protocol.

The draft is very interesting and I would be willing to collaborate, what is your main interest? Do you want to try to publish it as it is or would you be accepting feedback and include modifications?

Best regards
Sergio



El mar, 13 jul 2021 a las 17:37, Alan Frindell (<afrind=[e-mail]<mailto:[e-mail]>>) escribió:
Hi, for several years, Facebook has been using its own video ingest protocol over QUIC from our apps to our infra.  While we’ve spoken about it before, we just now published a draft documenting how it works:  https://www.ietf.org/archive/id/draft-kpugin-rush-00.html.

The protocol leverages the advantages of QUIC transport, and features a partially reliable mode using only QUIC v1 RST_STREAM.

We welcome your feedback

Thanks

-Alan Frindell





--
Wish mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/wish