Re: [V3] RIPT BoF approved for IETF 107

Joerg,

On Wed, Feb 19, 2020 at 1:32 PM Justin Uberti <juberti@google.com> wrote:

> Thanks for this paper, I think this is a good exploration of the space,
> especially the table on page 4.
>

I wanted to echo Justin's thanks for forwarding a link to your/Colin's
paper. It's very helpful.

Best,

Spencer

> Generally I think the substrate protocol gives us datagrams (or a suitable
> alternative), encryption, a global sequence number, and some parts of the
> necessary congestion control machinery, and the rest needs to be layered on
> top.
>
> On Wed, Feb 19, 2020 at 8:03 AM Joerg Ott <ott@in.tum.de> wrote:
>
>> Let me just point out here that there is still a dangling question
>> if one could leverage more state from QUIC than just offering a
>> datagram service.
>>
>> Colin and I went through some thought exercise to this end, but we
>> don't have an integrated implementation within QUIC for some RTP
>> features yet.  Still, our little analysis may turn out to be useful:
>> http://www.netlab.tkk.fi/~jo/papers/2018-12-epiq-quic-rtp.pdf
>>
>> Jörg
>>
>> On 19.02.20 16:57, Cullen Jennings (fluffy) wrote:
>> >
>> >
>> >> On Feb 14, 2020, at 10:00 PM, Ross Finlayson <finlayson@live555.com>
>> wrote:
>> >>
>> >> If we want to get something standardized/working quickly, then this is
>> a ’no brainer’, IMHO.  First, define a way to carry RTP/RTCP packets
>> directly in QUIC datagrams - in such a way that the existing RTP payload
>> format defined for each media type could map directly (i.e., with no more
>> media-specific IETF standardization work required).  Even if this means
>> that there's some duplication of functionality between RTP and QUIC
>> (datagrams).  (Ditto for RTP over QUIC (reliable) streams.)
>> >>
>> >> While - at some point in the future - it may be worthwhile defining a
>> new version (v3?) of RTP that works more efficiently with QUIC, this should
>> not be something that we require before we define/standardize a replacement
>> for SIP.  Otherwise it’ll be years before we’re done.  (RTP is starting to
>> show its age, but it’s not broken, and has lots of existing deployment that
>> could, ideally, be leveraged quickly within a SIP replacement.
>> >
>> > Almost no modern RTP implementation actually does the full RTP spec so
>> at the very least we need some serious subsetting of what part of RTP would
>> be mapped to QUIC. The RTP extension mechanism is badly broken particularly
>> for low bandwidth satellite links. And if you look at what RTP clients do
>> with the RTCP sent to them, well, I think there is some house cleaning
>> needed here to be able to actually use RTP /RTCP.
>> >
>>
>> --
>> V3 mailing list
>> V3@ietf.org
>> https://www.ietf.org/mailman/listinfo/v3
>>
>

Re: [V3] RIPT BoF approved for IETF 107 - Draft charter below