RE: A design for the Message frame(s)

["Lubashev, Igor" <[e-mail]>]

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=[e-mail]>
Sent: Monday, September 17, 2018 7:14 PM
To: Ian Swett <ianswett=[e-mail]>; Christian Huitema <[e-mail]>
Cc: [e-mail]; [e-mail]; Mike Bishop <[e-mail]>; Lars Eggert <[e-mail]>; IETF QUIC WG <[e-mail]>; Martin Thomson <[e-mail]>; Tommy Pauly <[e-mail]>
Subject: RE: A design for the Message frame(s)

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=[e-mail]<mailto:ianswett=[e-mail]>>
Sent: Monday, September 17, 2018 10:56 AM
To: Christian Huitema <[e-mail]<mailto:[e-mail]>>
Cc: Lubashev, Igor <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Mike Bishop <[e-mail]<mailto:[e-mail]>>; Lars Eggert <[e-mail]<mailto:[e-mail]>>; IETF QUIC WG <[e-mail]<mailto:[e-mail]>>; Martin Thomson <[e-mail]<mailto:[e-mail]>>; Tommy Pauly <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> wrote:



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