Subject: A design for the Message frame(s)

From: Ian Swett <[email-masked]>
Date: Wed, 12 Sep 2018 19:22:40 -0400

I wrote up a proposed API and framing for the MESSAGE frame(Issue #814
<https://github.com/quicwg/base-drafts/issues/814>)

The goal is for the MESSAGE frame to become an extension for QUIC v1, since
it could be very useful to applications such as WebRTC.  The timeline for
this is independent of QUIC v1 and I don't believe we need to spend time on
this in New York, but I'm interested in feedback and there is an
implementation
<https://chromium-review.googlesource.com/c/chromium/src/+/1219911> in the
latest Chrome canary when version 45 is enabled.

https://docs.google.com/document/d/18acTXqwP8D8nBjhJjTtRrP1eaSjyQSojTUYjPViC1Zc/edit#

Thanks, Ian

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Sep 2018 09:57:14 +1000

This obviously goes well into the details of an API choice that
shouldn't be relevant here, though I appreciate you sharing that extra
bit for context.

I think that the idea of a MESSAGE frame is a good one.  I expect that
many people will use it.  That number will likely be more than should
be using it in the same way that people often use UDP when they should
probably be using TCP, but at least with QUIC many of the facilities
of the transport remain: congestion control, consent to communicate,
encryption, etc...

Sure, those applications might lose flow control when they really
should be using it, they might fail to provide adequate authentication
when they really should be using it, and other such things, but the
baseline is so far above UDP that this seems like a clear win.

Do you plan to write a draft proposing this extension?  It seems like
a very short document.  And though I would be careful to avoid
spending too much of the time of this group before we finish our
primary goal, I would suggest that this is next on the menu.
On Thu, Sep 13, 2018 at 9:23 AM Ian Swett
<ianswett=[email-masked]> wrote:
>
> I wrote up a proposed API and framing for the MESSAGE frame(Issue #814)
>
> The goal is for the MESSAGE frame to become an extension for QUIC v1, since it could be very useful to applications such as WebRTC.  The timeline for this is independent of QUIC v1 and I don't believe we need to spend time on this in New York, but I'm interested in feedback and there is an implementation in the latest Chrome canary when version 45 is enabled.
>

---

From: Tommy Pauly <[email-masked]>
Date: Wed, 12 Sep 2018 17:18:37 -0700

> On Sep 12, 2018, at 4:57 PM, Martin Thomson <[email-masked]> wrote:
> 

Based on conversations we had with Ian in Montreal, I have actually just recently posted a draft to cover one way to add this extension (calling it a DATAGRAM frame rather than a MESSAGE, but it's really the same).

https://tools.ietf.org/html/draft-pauly-quic-datagram-00

I agree with you, Martin, that the approach should be left to be pretty simple, thus we have a pretty short draft for this. I think it provides an interesting way to allow applications currently using UDP or DTLS, often in conjunction with a control TCP stream, to have a more all-in-one solution.

Best,
Tommy

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Sep 2018 13:48:07 +1000

> https://tools.ietf.org/html/draft-pauly-quic-datagram-00

Hah, score one for Tommy.

> I agree with you, Martin, that the approach should be left to be pretty simple, thus we have a pretty short draft for this. I think it provides an interesting way to allow applications currently us…

Yep, or WebRTC-style applications can finally have a shared congestion
context for their diverse transport profiles, as noted by Ian.

(I can make your draft shorter in a few places, but it's all minor things.)

---

From: Lars Eggert <[email-masked]>
Date: Thu, 13 Sep 2018 09:20:44 +0300

Hi,

chair hat on.

I would ask that we postpone any discussion until after we've shipped the current set of documents to the IESG.

Lars

> On 2018-9-13, at 2:22, Ian Swett <ianswett=[email-masked]> wrote:
>

---

From: Ian Swett <[email-masked]>
Date: Thu, 13 Sep 2018 09:14:31 -0400

It was my intent to write a draft, but by the time I was going to start,
Tommy already started one.  I'm happy to work with Tommy if he'd like help.

Lars, previously we discussed the MESSAGE frame as an 'example extension'(
Issue#1482 <https://github.com/quicwg/base-drafts/issues/1482>), so even
though v1 doesn't depend upon this, I assumed they'd be completed around
the same time, but it sounds like that's not what you had in mind?  To
further clarify, would you prefer no official discussion of QUIC extensions
until after the current docs are shipped or just not this extension?

Thanks, Ian

On Wed, Sep 12, 2018 at 11:48 PM Martin Thomson <[email-masked]>
wrote:

> > I agree with you, Martin, that the approach should be left to be pretty
> simple, thus we have a pretty short draft for this. I think it provides an
> interesting way to allow applications currently using UDP or DTLS, often in
> conjunction with a control TCP stream, to have a more all-in-one solution.
>

---

From: Lars Eggert <[email-masked]>
Date: Thu, 13 Sep 2018 16:26:57 +0300

Hi,

On 2018-9-13, at 16:14, Ian Swett <ianswett=[email-masked]> wrote:
> Lars, previously we discussed the MESSAGE frame as an 'example extension'(Issue#1482), so even though v1 doesn't depend upon this, I assumed they'd be completed around the same time, but it sounds like that's not what you had in mind?  To further clarify, would you prefer no official discussion of QUIC extensions until after the current docs are shipped or just not this extension?

my fear is that anything beyond what we have already adopted as working items will delay the shipment of said adopted working items.

I'm very open for someone to make an argument why this would not cause such a delay, or why such a delay would be acceptable.

Lars

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 13 Sep 2018 13:42:44 +0000

Ian,

Thanks for writing and sharing this.

I’d love to find out more about “QUIC as a VPN (aka QBone)” but my Google search thinks I made a typo for a particular Pokémon. Is there anything public/shareable?

Is this an abstract API or is it targeted at say the Web Platform?

I’m also intrigued about the GetLargestOptimizedPayload function. Is it envisaged for this to be determined by Path MTU discovery?

Regards
Lucas

From: QUIC <[email-masked]> On Behalf Of Ian Swett
Sent: 13 September 2018 00:23
To: IETF QUIC WG <[email-masked]>
Subject: A design for the Message frame(s)

I wrote up a proposed API and framing for the MESSAGE frame(Issue #814<https://github.com/quicwg/base-drafts/issues/814>)

The goal is for the MESSAGE frame to become an extension for QUIC v1, since it could be very useful to applications such as WebRTC.  The timeline for this is independent of QUIC v1 and I don't believe we need to spend time on this in New York, but I'm interested in feedback and there is an implementation<https://chromium-review.googlesource.com/c/chromium/src/+/1219911> in the latest Chrome canary when version 45 is enabled.

https://docs.google.com/document/d/18acTXqwP8D8nBjhJjTtRrP1eaSjyQSojTUYjPViC1Zc/edit#<https://docs.google.com/document/d/18acTXqwP8D8nBjhJjTtRrP1eaSjyQSojTUYjPViC1Zc/edit>

Thanks, Ian

----------------------------

http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in error, please delete it from your system.
Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.

---------------------

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Thu, 13 Sep 2018 07:52:51 -0700

try: "QUIC" VPN -quick

This shows up
https://channels.theinnovationenterprise.com/articles/stealthy-vpn-services-from-consumer-playtoys-to-enterprise-threats

---

From: Ian Swett <[email-masked]>
Date: Thu, 13 Sep 2018 11:02:36 -0400

Thanks for the clever searching and interest in the QUIC VPN.  It's not
open source yet, but will be at some point in the future.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 14 Sep 2018 07:59:54 -0500

Thanks, Lars, for your note.

On Thu, Sep 13, 2018 at 8:27 AM Lars Eggert <[email-masked]> wrote:

> > Lars, previously we discussed the MESSAGE frame as an 'example
> extension'(Issue#1482), so even though v1 doesn't depend upon this, I
> assumed they'd be completed around the same time, but it sounds like that's
> not what you had in mind?  To further clarify, would you prefer no official
> discussion of QUIC extensions until after the current docs are shipped or
> just not this extension?
>
> my fear is that anything beyond what we have already adopted as working
> items will delay the shipment of said adopted working items.
>
> I'm very open for someone to make an argument why this would not cause
> such a delay, or why such a delay would be acceptable.
>

FWIW, I'm still counting on the working group to Do The Right Thing Without
My Opinions, but I'll be very interested in that conversation, even if it's
just with me as an interested listener ...

Spencer

---

From: Mike Bishop <[email-masked]>
Date: Fri, 14 Sep 2018 16:11:46 +0000

I fully agree that the current drafts are the higher priority, and that we shouldn't do anything that would jeopardize our ability to deliver them as soon as possible with high quality and confidence.  However, I'd argue that doing some work in this space is necessary to accomplish that goal.

The base drafts define an extension mechanism which is hypothetically sound, but hasn't been exercised.  To ensure the mechanism is sound in the real world, there's value in making some progress on an extension before everything is totally locked down.  Perhaps we discuss adopting the draft (or another) around the time we take the current documents to WGLC.  If we're going to credibly say that we have an extension model that works, I'd really like us to have interop on *some* extension before we say the draft is totally done.

Any issues we encounter can be considered WGLC or even IETF LC feedback, but I think I'd like to see some implementations passing some extensions around before we send the doc to the IESG.

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Lars Eggert
Sent: Thursday, September 13, 2018 6:27 AM
To: Ian Swett <ianswett=[email-masked]>
Cc: IETF QUIC WG <[email-masked]>; Martin Thomson <[email-masked]>; Tommy Pauly <[email-masked]>
Subject: Re: A design for the Message frame(s)

Hi,

Lars

---

From: Mikkel Fahnøe Jørgensen <[email-masked]>
Date: Fri, 14 Sep 2018 09:52:13 -0700

Another extension I was thinking might be worth adding is a custom
extension:

Reserve a single, or a small range of extension points that can be used
freely by cooperating entities for experimentation without needing IANA
registration. Otherwise it is likely that some code points would just be
squatted. If there are two code points, one could carry an identifier
string that other could carry payload. This could be formulated as an
official IANA extension.

Sorry for getting a bit off-topic here.

On 14 September 2018 at 18.13.17, Mike Bishop ([email-masked]) wrote:

I fully agree that the current drafts are the higher priority, and that we
shouldn't do anything that would jeopardize our ability to deliver them as
soon as possible with high quality and confidence. However, I'd argue that
doing some work in this space is necessary to accomplish that goal.

The base drafts define an extension mechanism which is hypothetically
sound, but hasn't been exercised. To ensure the mechanism is sound in the
real world, there's value in making some progress on an extension before
everything is totally locked down. Perhaps we discuss adopting the draft
(or another) around the time we take the current documents to WGLC. If
we're going to credibly say that we have an extension model that works, I'd
really like us to have interop on *some* extension before we say the draft
is totally done.

Any issues we encounter can be considered WGLC or even IETF LC feedback,
but I think I'd like to see some implementations passing some extensions
around before we send the doc to the IESG.

-----Original Message-----
From: QUIC <[email-masked]> On Behalf Of Lars Eggert
Sent: Thursday, September 13, 2018 6:27 AM
To: Ian Swett <ianswett=[email-masked]>
Cc: IETF QUIC WG <[email-masked]>; Martin Thomson <[email-masked]>;
Tommy Pauly <[email-masked]>
Subject: Re: A design for the Message frame(s)

Hi,

I'm very open for someone to make an argument why this would not cause such
a delay, or why such a delay would be acceptable.

Lars

---

From: "Charles 'Buck' Krasic" <[email-masked]>
Date: Fri, 14 Sep 2018 10:02:10 -0700

Hi Ian,  :)

I have a thought on the api aspect of your doc, just my two cents (not part
of my day job).

I wonder if the api could/should abstract over the distinction between
large small messages.   The implementation strategy might use the proposed
mechanism as an optimization for the case of messages small enough to fit
in the optimized payload size, but falls back to plain old streams for
larger messages (although OnMessageLost might only make sense in
combination with cancellation/ttl).   Is that what you had in mind?  If so,
it might be worth calling out as a suggestion.

Also, some clarity on what happens when congestion control or flow control
blocks sending might be worthwile.
https://tools.ietf.org/html/draft-pauly-quic-datagram-00
<http://draft-pauly-quic-datagram-00> section 5.1 says that the
implementation may drop the message.     It seems your proposed api would
signal OnMessageLost(), but maybe it would be advantages for an app to know
the connection is blocked before it attempts to send messages?
(OnConnectionBlocked/OnConnectionUnblocked() ?).    Of course, in a chrome
like api, it would be tricky since the binding of message to connection is
abstracted away (application has no connection handle/object), so maybe
surfacing the connection in the api is something appropriate for the
message use case?

-- Buck

---

From: "Lubashev, Igor" <[email-masked]>
Date: Sat, 15 Sep 2018 19:44:24 +0000

Given the amount of emails regarding Thai visas I am forced to read and delete, a thread on MESSAGE/DATAGRAM support is a welcome diversion.

I like that “MESSAGE” proposal does not require one’s messages to be under PMTU in size -- my largest concern with the DATAGRAM draft.  Taking a lesson from years of UDP experience, a transport abstraction providing atomic delivery of messages of somewhat arbitrary sizes is very useful (though the chances of successful delivery for larger messages drop off rapidly).

QUIC is an ACK-based transport, so I would expect it to do a better job of message delivery than UDP.  Namely, QUIC transport can try to retransmit lost messages or parts of messages, if the connection conditions allow it (i.e. no higher priority work to do).  Ian’s “MESSAGE” proposal uses STREAMs for large message delivery and is vague on when to reset the streams, implying that STREAM data may be retransmitted.  That’s a good thing, since it is the larger messages that benefit from retransmission of their parts the most.  MESSAGE frames are never retransmitted by transport, though, relying on the application to decide whether the retransmittion is needed.  This is somewhat unfortunate.

The MESSAGE proposal has no Flow Control of any kind for small messages (MESSAGE frames).  The receiver transport certainly needs to buffer those messages till the application is ready to consume them.  Is the intent for the receiver transport to just discard some MESSAGEs w/o a notification to the sender, if the receiver app is not fast enough?  If so, “message lost” callback cannot be relied on.  I think it is better to rely at least on the Connection flow control, as DATAGRAM draft does it.

Of course, MESSAGE/DATAGRAM lack transport-level message ordering and “message streams”.  (For those, one may want to look to Partially Reliable Message Streams.)  But this is a clear trade-off of features for simplicity (and some encoding efficiency).

  *   Igor

From: Charles 'Buck' Krasic <[email-masked]>
Sent: Friday, September 14, 2018 1:02 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; ianswett=[email-masked]
Subject: Re: A design for the Message frame(s)

Hi Ian,  :)

I have a thought on the api aspect of your doc, just my two cents (not part of my day job).

I wonder if the api could/should abstract over the distinction between large small messages.   The implementation strategy might use the proposed mechanism as an optimization for the case of messages small enough to fit in the optimized payload size, but falls back to plain old streams for larger messages (although OnMessageLost might only make sense in combination with cancellation/ttl).   Is that what you had in mind?  If so, it might be worth calling out as a suggestion.

Also, some clarity on what happens when congestion control or flow control blocks sending might be worthwile.  https://tools.ietf.org/html/draft-pauly-quic-datagram-00<https://urldefense.proofpoint.com/v2/url?u=http-3A__draft-2Dpauly-2Dquic-2Ddatagram-2D00&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=YtUaEKOiSwn0Nja53gHlTm8gjl-2_ePGne72MPxpu7w&s=ztZ5XNpgIAQQAHlRcF7P_0B9AUwNLkWG-NSn91FfxE4&e=> section 5.1 says that the implementation may drop the message.     It seems your proposed api would signal OnMessageLost(), but maybe it would be advantages for an app to know the connection is blocked before it attempts to send messages?  (OnConnectionBlocked/OnConnectionUnblocked() ?).    Of course, in a chrome like api, it would be tricky since the binding of message to connection is abstracted away (application has no connection handle/object), so maybe surfacing the connection in the api is something appropriate for the message use case?

-- Buck

On Fri, Sep 14, 2018 at 9:13 AM Mike Bishop <[email-masked]<mailto:[email-masked]>> wrote:
I fully agree that the current drafts are the higher priority, and that we shouldn't do anything that would jeopardize our ability to deliver them as soon as possible with high quality and confidence.  However, I'd argue that doing some work in this space is necessary to accomplish that goal.

-----Original Message-----
From: QUIC <[email-masked]<mailto:[email-masked]>> On Behalf Of Lars Eggert
Sent: Thursday, September 13, 2018 6:27 AM
To: Ian Swett <ianswett=[email-masked]<mailto:[email-masked]>>
Cc: IETF QUIC WG <[email-masked]<mailto:[email-masked]>>; Martin Thomson <[email-masked]<mailto:[email-masked]>>; Tommy Pauly <[email-masked]<mailto:[email-masked]>>
Subject: Re: A design for the Message frame(s)

Hi,

Lars

---

From: Christian Huitema <[email-masked]>
Date: Sat, 15 Sep 2018 19:09:09 -0700

On 9/15/2018 12:44 PM, Lubashev, Igor wrote:
>
> Given the amount of emails regarding Thai visas I am forced to read
> and delete, a thread on MESSAGE/DATAGRAM support is a welcome diversion.
>
>  
>
>  
>
> I like that “MESSAGE” proposal does not require one’s messages to be
> under PMTU in size -- my largest concern with the DATAGRAM draft. 
> Taking a lesson from years of UDP experience, a transport abstraction
> providing atomic delivery of messages of somewhat arbitrary sizes is
> very useful (though the chances of successful delivery for larger
> messages drop off rapidly).
>

There is somewhat of a continuum between sensor reports (e.g. the mouse
is now pointing at x=234, y=152), audio streams (short packets, 50 times
per sec), video streams (shortish packets, except those I frames that
are 64K long), and server pushed pages.

I think a pure "datagram" frame servers well the low end of the
continuum, such as sensors, for which there is no point at all repeating
the data. Just transmit a fresh value. Datagram works OK for audio, we
have been doing it for a very long time.

Pure datagram does not work too well for real-time  video, because
missing 10% of an I Frame is a real bummer. You need some extra sauce,
typically some form of FEC. But then, if you are ready to put that extra
sauce in the app, datagram is a pretty good building block. Especially
if you can get integrated congestion control and error reporting through
the integration with Quic.

So, personally, I would rather keep it simple, use a bare bone datagram
API, and let the application deal with the added complexity.

But then, frame types are cheap. We can have several extensions. No
point fighting about it.

-- Christian Huitema

---

From: Ian Swett <[email-masked]>
Date: Mon, 17 Sep 2018 10:55:33 -0400

To clarify, the largest intended difference between the MESSAGE proposal
and the DATAGRAM draft is the choice of name.  Both are designed to be
sub-MTU, because anything larger can be accommodated by a unidirectional
stream.  My doc goes into a lot more details on API, which aren't necessary
for the WG to consider, but I thought provided some rationale for why I
made the design choices I did and it was a useful guide to implement from.

Buck, originally I wanted a single API that abstracted away what was
underneath, but in the end all the applications I talked to were just as
happy dealing with it themselves, so it was dropped for now.

On the subject of whether the WG should spend any time on this, I tend to
agree with Mike that it would be good to know the extension mechanism
actually works, and this is a really easy frame to implement and specify,
so it's an excellent candidate for an example extension.  But for this week
in NY, I want to focus on resolving all the open issues so the editors can
write the needed text before Bangkok.

On Sat, Sep 15, 2018 at 10:09 PM Christian Huitema <[email-masked]>
wrote:

> Given the amount of emails regarding Thai visas I am forced to read and
> delete, a thread on MESSAGE/DATAGRAM support is a welcome diversion.
>
>
>
>
>
> I like that “MESSAGE” proposal does not require one’s messages to be under
> PMTU in size -- my largest concern with the DATAGRAM draft.  Taking a
> lesson from years of UDP experience, a transport abstraction providing
> atomic delivery of messages of somewhat arbitrary sizes is very useful
> (though the chances of successful delivery for larger messages drop off
> rapidly).
>
>
> There is somewhat of a continuum between sensor reports (e.g. the mouse is
> now pointing at x=234, y=152), audio streams (short packets, 50 times per
> sec), video streams (shortish packets, except those I frames that are 64K
> long), and server pushed pages.
>
> I think a pure "datagram" frame servers well the low end of the continuum,
> such as sensors, for which there is no point at all repeating the data.
> Just transmit a fresh value. Datagram works OK for audio, we have been
> doing it for a very long time.
>
> Pure datagram does not work too well for real-time  video, because missing
> 10% of an I Frame is a real bummer. You need some extra sauce, typically
> some form of FEC. But then, if you are ready to put that extra sauce in the
> app, datagram is a pretty good building block. Especially if you can get
> integrated congestion control and error reporting through the integration
> with Quic.
>
> But then, frame types are cheap. We can have several extensions. No point
> fighting about it.
>
> -- Christian Huitema
>

---

From: "Lubashev, Igor" <[email-masked]>
Date: Mon, 17 Sep 2018 23:14:07 +0000

I happened to think that an API description is critically important for the WG to consider (even if that description does not make it into the draft).  The API description provides a usability goal for the protocol to achieve.
For example, “OnMessageLost” is a useful callback.  If its semantics allows for false positives but no false negatives, we know some flow control of MESSAGE/DATAGRAM is required.

I am a bit surprised by the lack of desire for a homogeneous API for different message lengths.  I’ve seen too many systems that started out as “we just need to send small ‘sensor-like’ UDP packets” and then evolved over the years by adding more ‘sensors’ and more fidelity to the ‘sensors’, eventually relying on IP fragmentation to save them.  Due to the requirements of compatibility with old implementations, IP fragmentation turned out to be a savior for those UDP systems (as much as IETF might dislike that -- draft-bonica-6man-frag-deprecate).  Many companies we work for may be best positioned to keep updating our systems (servers and clients) to make timely protocol changes as the needs evolve.  However, I am worried that many other systems will be suffering ~10 years down the line without seamless (from app API perspective) extensibility on message length.  (I really do not want to see “MTU-extending” tunnels out there!)

  *   Igor

From: Ian Swett <ianswett=[email-masked]>
Sent: Monday, September 17, 2018 10:56 AM
To: Christian Huitema <[email-masked]>
Cc: Lubashev, Igor <[email-masked]>; [email-masked]; Mike Bishop <[email-masked]>; Lars Eggert <[email-masked]>; IETF QUIC WG <[email-masked]>; Martin Thomson <[email-masked]>; Tommy Pauly <[email-masked]>; [email-masked]
Subject: Re: A design for the Message frame(s)

To clarify, the largest intended difference between the MESSAGE proposal and the DATAGRAM draft is the choice of name.  Both are designed to be sub-MTU, because anything larger can be accommodated by a unidirectional stream.  My doc goes into a lot more details on API, which aren't necessary for the WG to consider, but I thought provided some rationale for why I made the design choices I did and it was a useful guide to implement from.

Buck, originally I wanted a single API that abstracted away what was underneath, but in the end all the applications I talked to were just as happy dealing with it themselves, so it was dropped for now.

On the subject of whether the WG should spend any time on this, I tend to agree with Mike that it would be good to know the extension mechanism actually works, and this is a really easy frame to implement and specify, so it's an excellent candidate for an example extension.  But for this week in NY, I want to focus on resolving all the open issues so the editors can write the needed text before Bangkok.

On Sat, Sep 15, 2018 at 10:09 PM Christian Huitema <[email-masked]<mailto:[email-masked]>> wrote:

There is somewhat of a continuum between sensor reports (e.g. the mouse is now pointing at x=234, y=152), audio streams (short packets, 50 times per sec), video streams (shortish packets, except those I frames that are 64K long), and server pushed pages.

I think a pure "datagram" frame servers well the low end of the continuum, such as sensors, for which there is no point at all repeating the data. Just transmit a fresh value. Datagram works OK for audio, we have been doing it for a very long time.

Pure datagram does not work too well for real-time  video, because missing 10% of an I Frame is a real bummer. You need some extra sauce, typically some form of FEC. But then, if you are ready to put that extra sauce in the app, datagram is a pretty good building block. Especially if you can get integrated congestion control and error reporting through the integration with Quic.

So, personally, I would rather keep it simple, use a bare bone datagram API, and let the application deal with the added complexity.

But then, frame types are cheap. We can have several extensions. No point fighting about it.

-- Christian Huitema

---

From: "Lubashev, Igor" <[email-masked]>
Date: Tue, 18 Sep 2018 20:21:51 +0000

Thinking more about this, the proposed simple “sendMessage()” API that sends arbitrary-sized MESSAGE/DATAGRAM frame is sufficient.  That API would make sure that a sufficiently large QUIC/UDP packet is sent, possibly fragmented by the IP layer.  This would work as well (or as poorly) as today’s UDP, but it will have an advantage of degrading slowly as messages starts to exceed PMTU instead of failing abruptly at that point.

  *   Igor

From: Lubashev, Igor <ilubashe=[email-masked]>
Sent: Monday, September 17, 2018 7:14 PM
To: Ian Swett <ianswett=[email-masked]>; Christian Huitema <[email-masked]>
Cc: [email-masked]; [email-masked]; Mike Bishop <[email-masked]>; Lars Eggert <[email-masked]>; IETF QUIC WG <[email-masked]>; Martin Thomson <[email-masked]>; Tommy Pauly <[email-masked]>
Subject: RE: A design for the Message frame(s)

  *   Igor

From: Ian Swett <ianswett=[email-masked]<mailto:ianswett=[email-masked]>>
Sent: Monday, September 17, 2018 10:56 AM
To: Christian Huitema <[email-masked]<mailto:[email-masked]>>
Cc: Lubashev, Igor <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Mike Bishop <[email-masked]<mailto:[email-masked]>>; Lars Eggert <[email-masked]<mailto:[email-masked]>>; IETF QUIC WG <[email-masked]<mailto:[email-masked]>>; Martin Thomson <[email-masked]<mailto:[email-masked]>>; Tommy Pauly <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: A design for the Message frame(s)

-- Christian Huitema