Subject: [AVT] Comments (1) on draft-ietf-avt-mwpp-midi-rtp-02.txt

From: Dominique Fober <[email-masked]>
Date: Wed, 6 Mar 2002 20:30:17 +0100

Hi,

Some questions and comments on draft-ietf-avt-mwpp-midi-rtp-02.txt. 
In order to facilitate reading and discussion, I've split them in 2 messages: the first one (this one) is about the core draft and another one
(should follow) about the appendix.
Best,
----------------------------------------------
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/

>3. MIDI Command Section
...

>Other complete MIDI commands may appear between SysEx command
>segments, including verbatim MIDI SysEx commands (for pseudo-wire
>emulation applications, only System Realtime commands may appear between
>SysEx command segments).

I'm not convinced by the usefulness of interleaving MIDI commands into 
SysEx segments. First : what's the time status of such a MIDI command ?
I guess that its delta time is equal to the container SysEx delta time.
As MIDI prevents such interleaving, it means that such a situation shouldn't
be found in a common real-time context. But it may occur if the sender is 
mixing different streams and receiving a MIDI command while a SysEx 
transmission has been started. On receiver side there are 2 solutions to 
play such a stream: 
- waiting for the SysEx completion and playing the SysEx followed by
its possible interleaved commands: in this case interleaving is useless
- or playing the interleaved commands as soon as possible but then, doesn't
it result in a time ordering inversion ?
Another point is that on receiver side and without interleaving, a common
MIDI parser may be applied to the incoming stream otherwise, one have to 
design a more sophisticated parser.
But maybe you have in mind some other use that I don't see.

...

>Only SysEx commands that terminate with an F7 octet may be encoded in
>MWPP. To encode SysEx commands using the dropped F7 construction, insert
>an F7 into the MIDI stream before performing MWPP command encoding. A
>pseudo-wire emulation encoding MAY set the execution time of the MIDI
>command that terminated the original SysEx command to indicate a one-
>octet overlap. Pseudo-wire emulation transcoders MAY recognize the
>execution-time overlap as coding a dropped F7 in the original SysEx
>command, and reproduce the dropped construction on the physical MIDI
>layer.

The question is: how the execution time setting may indicate a one-octet
overlap ? (and how is it recognized by transcoders ?)

>4. The Recovery Journal
...
>If the A bit is set in the recovery journal header, the recovery journal
>is "empty", and contains no channel journals. If the A bit is clear, the
>channel journal list contains (TOTCHAN + 1) channel journals.

You may save the A bit if TOTCHAN (and not TOTCHAN + 1) indicates the number
of channel journals and TOTCHAN = 0 denotes an empty recovery journal.

Note about the R bit: in <draft-lazzaro-avt-mwpp-midi-nmp-00.txt> was a 
general mention about the R bit:
>All reserved bits in this memo are named R: reserved bits MUST be set to 
>zero by senders and ignored by receivers.
It has been removed with the corresponding paragraph and now, it's first
mentionned only in the appendix.

>5. Checkpoint Packet Policy

>(Editors note: MWPP as defined in this version of the memo provides
>resiliency for MIDI Channel commands only; upcoming iterations will add
>partial MIDI Systems resiliency. 

Isn't the TOC size (section 4) a little bit short if you plan to add
resiliency for non-channel messages ?

...

Another question is: shouldn't the sender behavior be more normative 
concerning the recovery journal setup according to the checkpoint packet 
sequence number. Actually, what is a sender supposed to do when it 
advances the sequence number ? is it allowed to drop datas which occured
prior to the checkpoint from the journal ? and in this case, 
how is a receiver informed of this policy ?

[Section removed from  <draft-lazzaro-avt-mwpp-midi-nmp-00.txt>]
>4. Sender Addendum: Guard Packets
I understand that guard packets policy is implementation dependant and
that normative recommendations has been removed. However, apart of the
resiliency goal mentionned in <draft-lazzaro-avt-mwpp-midi-nmp-00.txt>,
guard packets may also be used to ensure that the receiver may compensate 
its clock skew with a good acuracy. In this case, the receiver has to
receive packets at a minimum rate. 
Don't you think that it would be usefull to keep recommendations about 
guards packets at least within the appendix ?

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

---

From: John Lazzaro <[email-masked]>
Date: Thu, 14 Mar 2002 14:40:28 -0800

---

> Martijn Sipkema writes:
>
> Should the 0x10 0x00 then be followed by a delta time or is a sysex
> segment/command not ending with a oxf7 only allowed to be followed
> by a 0 delta time?
>
> If yes, why?
>
> If no, why use 2 bytes?
>
> As i suggested earlier one could use a any status
> byte, except 0xf7/0xf0 (as I erroniously suggested using) for terminating 
> the sysex segment/command, e.g. 0xff.

An open issue at the moment is the exact meaning of delta-times -- the
next version of the memo (-03.txt) will take into account the
pseudo-wire-emulation issues raised by you and Dominique in WG
discussions, and change delta-time semantics. These changes impact the
best way to code dropped F7s (as your first question above notes).

So, I think the best thing to do is to wait until -03.txt comes out,
and continue the dropped F7 discussion then ... I can't really judge
the "alternative status byte" vs. "multiple delta-time zeros"
solutions until I see them in the context of the new delta-time
semantics.

---

> Martijn Sipkema writes:
>
> Also why was:
>
>    -----------------------------------------------------------
>   | Sublist Position |  Head Status Octet | Tail Status Octet |
>   |-----------------------------------------------------------|
>   |    first         |       0xF0        |       0xF0         |
>   |-----------------------------------------------------------|
>   |    middle        |       0xF7        |       0xF7         |
>   |-----------------------------------------------------------|
>   |    last          |       0xF7        |       0xF0         |
>    -----------------------------------------------------------
>
>   chosen instead of:
>
>
>    -----------------------------------------------------------
>   | Sublist Position |  Head Status Octet | Tail Status Octet |
>   |-----------------------------------------------------------|
>   |    first         |       0xF0        |       0xF0         |
>   |-----------------------------------------------------------|
>   |    middle        |       0xF7        |       0xF0         |
>   |-----------------------------------------------------------|
>   |    last          |       0xF7        |       0xF7         |
>    -----------------------------------------------------------
>
> which would be more like the wire protocol where a sysex
> command is also terminated with a 0xf7.

Yes, this looks like a better encoding, I'll switch to this in
-03.txt, unless an issue comes up during the design.

-------------------------------------------------------------------------
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: Thu, 14 Mar 2002 19:09:40 -0800

This posting takes up the other open MWPP thread: non-monotonicity
support.

----

> "Martijn Sipkema" writes:
>
>
> [... method description deleted ...]
>
>
> Basically what I'm suggesting is to have Z = 0 mean
> * implicit 0 delta times
> * no monotonicity required with the timestamped commands
>

The multi-stream approach provides non-monotonicity support in a
superset of the situations this method provides. In addition,
multi-stream support needs to be in the standard for other reasons
(SysEx bulk dumps).

So the question becomes, do the benefits of adding this second way to
do non-monotonicity outweight the any disadvantages?

My basic problem with adding non-monotonicity within a single stream,
is that the recovery journal system was designed to work in a
monotonic stream. I don't even know if I can make it work in the
general case (multicast UDP, with receivers joining and leaving during
the session, keeping the guarantee during arbitrary packet loss) for
non-monotonic streams.

If its possible, though, a lot of work is involved: rethinking the
system behavior to find where non-monotonicity matters, rewriting the
affected appendices, and doing a new sfront prototype to validate the
extensions (especially the memory/CPU efficiency of send/receive).

I don't think its worth going down this path, especially since the
likely MWPP "early adopter" applications -- streaming GM files,
real-time network musical performance over WANs using MIDI keyboards,
network appliances that do pseudo-wire emulation of a physical MIDI
cable over a LAN -- don't need non-monotonicity. The applications that
do are the more complex ones, and are more likely to add multi-stream
support; the benefit of adding intra-stream non-monotonicity may be
small in practice.