Subject: [AVT] Re: MWPP slides for Yokohama available for download

From: Colin Perkins <[email-masked]>
Date: Fri, 26 Jul 2002 13:36:07 -0400

[Taking this to the mailing list, since we're getting into discussion;
 edited to remove purely editorial and procedural comments]

--> John Lazzaro writes:
>Hi Colin,
>
>Thanks for the detailed comments, -05.txt is now in preparation and so
>hopefully I can fold most of these changes into the document, although
>a few might need more thought to find the best solution.
>
>Detailed replies below ... mostly in order, although I start with
>your last comment about non-guaranteed mode ...
>
>
>> Or maybe non-guaranteed mode is not useful? What do you gain for the
>> loss in reliability?
>
>I'm still in the process of cataloging the range of situations where
>it may be useful, but I can describe one in detail for you: MIDI file
>content streaming without the use of RTCP.

This is a good point. While we hope RTCP is used, there are certainly some
cases where a backchannel is not available, and we should support those.

>The only way to accomplish this task in "guaranteed mode" is to never
>update the checkpoint packet. In many contexts, this will work OK --
>if a few rough edges of the MIDI command language are avoided, the
>recovery journal won't grow without bound, but will limit to a fixed
>value. However, if the MIDI stream being sent is complex, and if the
>composition is long-lived, the bandwidth overhead that results if the
>recovery journal is never trimmed may be too high.
>
>Non-guaranteed mode provides a way out:
>
>  -- Senders generate constant-bandwidth streams, incrementing the
>     checkpoint packet of the recovery journal as needed to prevent
>     going over the bandwidth limit. Or perhaps, use some other 
>     sending scheme that does not require RTCP feedback.
>
>  -- Receivers keep track of the checkpoint packet sequence number
>     and the history of lost packets, and detect when so many packets
>     have been lost that the recovery journal doesn't provide protection
>     (the G bit simplifies this tracking). In this case, the receiver
>     does some "worst case" behaviors to reset state (example: fix any
>     stuck note issues by cancelling all notes in progress).
>
>However, as a few recent MIDI expert comments have noted, for some
>classes of MIDI commands, there is no "worst case" action the receiver
>can take (example: if the sender raises the volume for a channel from
>64 to 32, and this command is lost during a string of losses that
>"overflow" the checkpoint packet depth, the receiver has no way of
>knowing its now playing that channel twice as loud as requested. Note
>that this "overflow" cannot happen if the guarantee is in effect).
>
>However, with sender help, there is a way out -- senders can implement
>a "carosel" scheme, resending items like volume at fixed intervals.

This is getting very domain specific. Is it possible to define sensible
worst case recovery actions for all the commands? 

>So, assuming the details of this example are typical of the other
>situations where non-guaranteed mode may be used, what are the
>options?
>
> [1] Given the complexity of defining sender and receiver
>     behavior in the non-guaranteed case, we conclude its better
>     not to support non-guaranteed mode at all -- let the options of
>     "use RTCP" or "never update the checkpoint packet" suffice.
>
> [2] We can permit non-guaranteed mode, and provide extensive
>     guidance of sender and receiver behavior required to use
>     it successfully (i.e. cataloging MIDI commands into "safe"
>     and "non-safe", defining carosel schemes, etc.). 
>
> [3] We can permit non-guaranteed mode, provide no detailed 
>     guidance, but instead generally warn implementors of the
>     dangers involved.
>
>Basically, [1] and [2] yield the highest quality standard, [2] and [3]
>yield the most flexible standard, but the added increment of document
>complexity for [2] over [1] and [3] is non-trivial. [2]'s complexity
>may also include legal uncertainty -- there may be MPEG LA claims on
>data carosels, although I don't actually know this for a fact. Note
>that guaranteed mode does not use caroseling.

Option [3] may make most sense, provided we have a means of reasoning about
the probability of unrecoverable errors, and the tradeoff between bandwidth,
complexity and reliability. 

>> - What is the definition of the RTP timestamp? That draft says "If the MIDI
>>   command section of the MWPP payload contains no MIDI commands, the RTP
>>   timestamp indicates the instant the RTP packet was encoded" which is the
>>   usual sampling instant definition, but what if the command section does 
>>   contain MIDI commands?
>
>Yes, I agree, the RTP timestamp meaning for both cases needs to be
>defined in the same place in the document. If the MIDI Command section
>has commands, the RTP timestamp acts as the "base timestamp" to be
>used in calculating the command timestamps for each MIDI command,
>using the delta time method described in Section 3. 
>
>As currently written, MWPP considers the "instant the RTP packet was
>encoded" to be the command timestamp of the _last_ MIDI command in the
>MIDI command section -- it uses this definition for several recovery
>journal definitions.
>
>However, if there are RTP-related issues with using "last MIDI
>command" instead of "first MIDI command" for the "instant the RTP
>packet was encoded" let me know -- I can define a new term meaning
>"the command timestamp of the last command, or the RTP timestamp if
>the MIDI command section holds no commands" and use that term in the
>recovery journal text instead of "instant the RTP packet was encoded."

Using "last MIDI command" may affect the jitter calculation, I'll have to
think more about it.

>> The drafts says "RTP timestamps do not necessarily increment at a fixed
>> rate". This is, presumably, because packets are not necessarily sent at 
>> a fixed rate?
>
>Yes, the quoted sentence is too terse as written, I'll rewrite
>it. Basically, if MWPP is being used for low-latency interaction (say,
>encoding the output of a musician playing a keyboard), the RTP sending
>sequence reflects the timing of gestures (key depressions, etc), and
>probably a "one packet per gesture" coding will be used, and thus
>packets won't be sent at a fixed rate.
>
>However, if MWPP is being used for streaming a MIDI File, it might
>make sense to send RTP packets at a fixed rate, with hefty MIDI
>command sections holding the dozens of commands that execute during
>that interval. This would reduce the impact of header overhead, and
>might also help compatibility with streaming server software.

Okay.

>> - How are multiple MIDI channels coded? Is this implicit in the MIDI
>>   command set?
>
>       Yes. The explanation that follows will be a part of the new
>MIDI overview section:
>
>
>   The first octet of a MIDI command has the format 0b1pppnnnn. If ppp
>   in the range 000 to 110, the command is a "voice command", the ppp
>   codes the opcode type (for example, 000 is NoteOff, 001 is NoteOn,
>   etc), and nnnn indicates which of 16 MIDI channels the command
>   executes on. If ppp equals 111, the command executes on the Systems
>   channel, and the nnnn codes the Systems opcode type (for example, nnnn
>   = 0001 codes the MIDI Quarter Frame message, which is the timing pulse
>   for the SMPTE time code mechanism for MIDI).
>
>
>	This multiplexing does bring up a tricky session initiation
>issue with regard to multicast: one can imagine one sender (say, a
>sequencer program) and many listeners (say, a few rack-mount synths)
>for a single multicast MWPP RTP stream, with each listener responding
>to a specific MIDI channel, and each only needing session initiation
>for that specific channel. For example, one listener may be a
>Structured Audio decoder that is listening to MIDI channel 12 on an
>RTP stream, and a second listener may be proprietory synth (with a
>defined render value and SDP parameters to support configuration) that
>is listening to MIDI channel 14.
>
>	These two listeners are listening to the same RTP multicast
>stream, but each needs a separate configuration during the session
>initiation process for the session. I read through RFC 3264 (the new
>Offer/Answer protocol RFC that was broken out of the main SIP RFC) a
>few times, and couldn't quite figure out if its rules for multicast
>sessions would work for this "separate configuration" requirement.

I'm not sure, because of the data being part of a single RTP session. You'd
probably have to invite each separately?

>> Why are timestamp deltas cumulative, rather than each being relative to
>> the RTP timestamp?
>
>The cumulative method is used by Standard MIDI File method of delta
>times; since MWPP's delta times are a modified version of MIDI File
>delta times, it seemed like a good idea to stick as closely as
>possible to that algorithm. In addition, there is an efficiency
>argument: delta times may be 1-4 octets, and the accumulation approach
>maximizes the number of 1-octet timestamps.

Okay.

Cheers,
Colin

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: John Lazzaro <[email-masked]>
Date: Mon, 29 Jul 2002 10:55:15 -0700

> Colin Perkins writes:
>
> I assumed the parameters of the session meant properties such as the address, 
> ports, codec, etc (i.e. all receivers listen to the same session). I think
> the behaviour you require is okay.

Great, multicasting a single MIDI stream on a LAN to a group of 
rack-mount synths should work with offer/answer, then ... 

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------

---

From: John Lazzaro <[email-masked]>
Date: Tue, 30 Jul 2002 14:01:02 -0700

> Dominique Fober writes:
>
> [... several suggestions on non-guaranteed text for -05.txt ...]
>
> These are just some ideas as they come. I'll try to
> think some more about the problem...

Yes, please do, its very helpful -- the current plan is a late-August
or early September -05.txt release, with the primary goal of fixing
a set of related recovery-journal issues of this type that MIDI and
IETF experts have sent in since -04.txt, and a secondary goal of
fixing up editorial issues. 

> I'm also considering that using "last MIDI command" may affect the
> jitter calculation and at least it'll make the calculation
> significantly more complex.

OK, it really sounds like decoupling the definitions meant for RTP
jitter calculations and the definitions the recovery journal needs
for its own internal logic is the best way to proceed ...