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

From: John Lazzaro <[email-masked]>
Date: Fri, 26 Jul 2002 18:26:06 -0700

[ options under discussion, for reference ... ]

 [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.

> Colin Perkins writes:

[...]

>
> 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.

[...]

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

[...]

> 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.

There may be a happy medium between the [2] and [3] -- text that
partitions the responsibility for non-guaranteed "worst-case recovery"
to senders, receivers, or both, for each part of MIDI. This text would
describes in an abstract way the resiliency issue involved, but would
refrain from algorithmic descriptions.

I'll work on trying to find this sort of solution for the -05.txt, and
revert to [3] as the fallback if the attempt is unsuccessful. So,
non-guaranteed mode will remain in MWPP in a form somewhere on the
[2]-[3] continuum.

--------

> Colin Perkins writes:
>
>> John Lazzaro writes:
>>
>>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.

OK, I'll provisionally change -05.txt to use "first MIDI command" for
"instant the RTP packet was encoded", and define a new term for
recovery journal use. I'll do it in such a way that it will be easy to
undo the change if it is found to be unnecessary ... Appendix A.1
already is devoted to recovery-journal-specific definitions, so adding
one more is not difficult to do.

--------

> Colin Perkins writes:
>
>> John Lazzaro writes:
>>
>>	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?

Yes, the sender would invite each receiver to the multicast session
independently, with an SDP customized to the receiver.  But all
receivers would listen in on the same RTP multicast, picking off a few
MIDI channels and synthesizing audio for it, using the rendering
method specified by its custom SDP.

It wasn't clear to me if this scenareo would be legal under RFC 3264,
but perhaps I was misreading it in some way ...

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

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

---

From: Colin Perkins <[email-masked]>
Date: Mon, 29 Jul 2002 13:08:08 -0400

--> John Lazzaro writes:
...[snip]...
>but perhaps I was misreading it in some way ...

I don't see why it wouldn't be legal.

Colin

---

From: Dominique Fober <[email-masked]>
Date: Tue, 30 Jul 2002 15:27:11 +0200

>refrain from algorithmic descriptions.

I'm inclined to think that a good medium between [2] and [3] would be to provide an extensive guidance on server side only. Maybe the server behavior in case of  non-guaranteed mode could be more specified by MWPP. It could for example retain space in the recovery journal in order to keep a constant and comfortable offset between the packet seqnum and the checkpoint seqnum. In this case, a failure on client side would mean that several packets have been lost which is a less probabilistic case.
Another issue is the empty packet: a client missing an empty packet may apply "worst case" action which would be the worst decision. In fact, the most annoying problem is that a client can't figure out the server behavior in case of non-guaranteed mode. In case of an empty packet for example, a server should be allowed to move the checkpoint seqnum but the client should be informed that the move concerned an empty packet.
These are just some ideas as they come. I'll try to think some more about the problem...

>one more is not difficult to do.

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.

----------------------------------------------
Dominique Fober               <[email-masked]>
----------------------------------------------
GRAME - Centre National de Creation Musicale -
9 rue du Garet  69001 Lyon France
tel:+33 (0)4 720 737 06 fax:+33 (0)4 720 737 01
http://www.grame.fr