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

From: John Lazzaro <[email-masked]>
Date: Sat, 9 Mar 2002 19:44:42 -0800

> Dominique Fober writes:
>
> 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.

Part 1 comments inline below ... thanks again for your comments ...

-----

> Dominique Fober writes:
>
> I'm not convinced by the usefulness of interleaving MIDI commands into
> SysEx segments.  [...] But maybe you have in mind some other use that I
> don't see.

This feature seems to be getting a fair amount of negative feedback,
maybe its best for it to be deleted. Here's an explanation of why its
there, let me know what you think of my justification ...

 o Imagine a MIDI controller keyboard and a rack-mount synth, both
   with Ethernet jacks that speak MWPP. Imagine they connect via a
   crossover cable, or some other means which is going to be "reliable"
   (perhaps TCP, or a switched fabric known not to drop packets ...).

 o Imagine the controller keyboard has the ability to send some sort of
   useful bulk data to the synth, via SysEx.

 o Image you want to play real-time NoteOns and NoteOffs as the 
   "foreground process", while sending the bulk data as a "background
   process," instead of stopping real-time work during the data transfer.

The SysEx feature lets you do bulk transfer "in the background" in a
clean way, by breaking up the bulk data SysEx into segments,
interleaving the MIDI NoteOns and NoteOffs wherever they need to
be. Whereas, if you didn't allow this feature, you'd be forced to have
two MWPP sessions going on, or you'd have periods of time where 100%
of the MWPP bandwidth was devoted to the bulk data, because there was
no way to express in MWPP the NoteOn command interleaving, even though
your device could easily handle playing the NoteOns and collecting the
bulk data at the same time.

Of course, most musical hardware won't have these Ethernet jacks, and
a MIDI cable stands in the way. For that case, we negotiate the "pwe"
SDP parameter to be 1 during session initiation, so that the MWPP
stream is MIDI-cable-ready -- the MIDI command timings will always fit
onto the cable w/o overlap, and the SysEx interleave construct won't
be used, as noted by the parenthetical remark in this section of the
memo:

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

So the simple answer to the sub-questions you detailed on this issue is:

   If you make your session a pwe=1 session, you'll never see a 
   SysEx command interleaved with a MIDI NoteOn command. And so,
   you'll never need to handle the issue of "I can't physically
   send this combination over a MIDI cable." The pwe=0 semantics
   are there so that you're able to send MWPP streams without the
   restrictions, if you ever need to do so.

One detailed comment:

> Dominique Fober writes:
>
> 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. 

Yes, if you break up a SysEx command into three segments, the three
delta times pin down the timing of the first octet of each segment.
In the case of "pwe=1", these delta-times must be chosen so that you
can fit the number of octets in each segment onto the MIDI cable
(along with any System Realtime commands coded between the segments).
Whereas, a "pwe=0" is under no such requirement, since its designed
for situations where MIDI command transport and execution "in
parallel" is encouraged.

-----

> Dominique Fober writes:
>
>>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 ?)

Good point, this text is too vague to be useful. I'll come up with a
candidate phrasing of exact semantics that is easy to code and easy to
recognize, and add it into the next draft update ... let me know what
you think of it.

-----

> Dominique Fober writes:
>
>>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.

There's 17 possibilities: 0 channel journals, 1 channel journal, ...
15 channel journals, 16 channel journals. If we let TOTCHAN be the
number of channel journals, we couldn't code the case of all 16 MIDI
channels needing a journal.

-----

> Dominique Fober writes:
>
>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 mentioned only in the appendix.

Thanks; I'll fix that in the next draft.

-----

> Dominique Fober writes:
>
>>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 ?

The MIDI Systems resiliency won't be coded under the channel journal,
so it won't need TOC bits. Instead, the remaining R bit in the
top-level recovery journal structure will become a X bit, that codes
the presence of a System Journal before the Channel Journals. Here's a
preliminary figure from the next version of the memo:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|A|G|X|TOTCHAN|    Checkpoint Packet Seqnum   | System Journal|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    ... (only if X == 1) ...   |  Channel journals ....        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 7 -- Top-level recovery journal format

-----

> Dominique Fober writes:
>
> 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 ?

I agree, the final formation of sender policy is still under
development, thanks for your feedback on it. However, there is a fair
amount of required behavior already in the document. In each Appendix:

   A channel journal contains Chapter ZZZ if an active MIDI ZZZ command
   on this channel is present in the MIDI command section of an earlier
   packet, back to and including the checkpoint packet.

normatively defines the relationship between the checkpoint packet and
what needs to be in the journal; also, there's usually secondary text
in each Appendix, on the order of:

  The ZZZ field codes the value about the most recent active MIDI ZZZ
  command on the channel. 

So, basically, the sender gets to choose what the checkpoint packet
is, and the normative text defines what needs to be in the recovery
journal given that choice. In fact, the requirements in the Appendices
are pretty harsh, in that they force full coverage of all MIDI
commands; one change I'm considering is SDP to select a subset of MIDI
commands to protect.

Other sender-related normative items in the current memo include:

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|A|G|R|TOTCHAN|    Checkpoint Packet Seqnum   | Channels ...  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

            Figure 7 -- Top-level recovery journal format

The sender is forced to identify the checkpoint packet in the
"Checkpoint Packet Seqnum" field.  Also, if G = 1, it has to move the
checkpoint forward with accordance with the policy. So, with that
background, let's revisit the specific questions:

> Actually, what is a sender supposed to do when
> it advances the sequence number ?

Every time it sends a packet out (assuming the SDP parameter rj=1),
it has to make sure each chapter in the recovery journal meets the:

   A channel journal contains Chapter ZZZ if an active MIDI ZZZ command
   on this channel is present in the MIDI command section of an earlier
   packet, back to and including the checkpoint packet.

and the

  The ZZZ field codes the value about the most recent active MIDI ZZZ
  command on the channel. 

texts. So, if the checkpoint packet advances, it can very well be that
MIDI commands that were represented in the journal no longer have to
be, because they occurred before the (new) checkpoint packet position

It also has to update the "Checkpoint Packet Seqnum" field. And if the
G=1 bit is set, its updating must be consistent with the policy.

> is it allowed to drop datas which occured prior to the checkpoint 
> from the journal ? 

Yes, see above.

> and in this case, how is a receiver informed of this policy ?

At the very least, by the Checkpoint Packet Seqnum field.

However, if G=1, the receiver doesn't care -- the policy is written so
that the checkpoint packet only updates when every known receiver has
either received or recovered from all MIDI commands that will be
removed from the journal post-checkpoint-update. That's the
"guarantee" the policy makes.

If G=0, that guarantee doesn't apply -- however, the receiver can
always sense what is going on by tracking the Checkpoint Packet Seqnum
field. This sort of tracking takes work to do well -- examining and
saving parts of every recovery journal, not just a recovery journal
that occurs after a packet loss. This is why G=1 is the preferred
choice, because it provides a guarantee, and it reduces the receiver
burden.

-------

> Dominique Fober writes:
>
>>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 accuracy. 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 ?

Another good point, I had not considered the clock skew issues here.
Options would seem to including (1) adding to the main memo with a
"recommended" (2) adding an SDP method to request a skew-sensitive
sending procedure, or (3) adding it an Informational RFC which covers
sending and receiving algorithms in detail, which clearly needs to be
written as a companion to the normative memo ... I tend to lean
towards (3), but maybe there's a good reason for (1) and (2) instead.

-------------------------------------------------------------------------
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: Dominique Fober <[email-masked]>
Date: Wed, 13 Mar 2002 12:27:19 +0100

> John Lazzaro writes:

You're certainly right concerning interleaving with your example however,  my feeling is that the transmission speed on alternate physical layers allow to obtain the same result without interleaving. Lets take the example of an Ethernet 10Mb network: you can transmit 1Kb in less than 1 ms. In your example, and to justify interleaving, transmitted sysex size should be greater than 1kb to interfere with notes playing. Moreover, we may consider that Ethernet 100Mb is now very widespread.

> John Lazzaro writes:

One point was not really clear to me up to now and reading your reply and rereading the draft, I deduce that in the case of "pwe=1", delta-times should be adjusted by the sender to "real-time transmission" and in particular, a zero delta time is forbidden as commands are serialized on the MIDI wire.
I'm wondering about the usefulness and even the semantic of such time stamping: actually, as MIDI bytes are queued on the MIDI wire, conversion from a zero delta time to 'n' usec will be done naturally. Moreover, it seems to me that this mechanism operates most of the time as only the beginning of the command if time stamped: for example with a large sysex, only the transmission time of the first byte is specified and the remaining bytes are queued to be transmitted as fast as possible.
It also seems to me that it results in an ambiguity: lets say that you are regularly transmitting a 250 bytes sysex every 80 ms. In fact, 80 ms is the time required to transmit the command on the MIDI wire. A receiver won't be able to decide wether the sender intention was to send the commands as fast as allowed by MIDI or to indicates a 80 ms delay between them, which is different as soon as one wants to make time transformations for example.

Another point is that MIDI rate indicates clearly a 320 usec delay between 2 transmitted bytes but how to precislely code this delay when time is expressed in various rates specified by the SDP rtpmap. For example: with a 44100 (Hz) srate, one MIDI byte corresponds to 14,112 time units (15,36 for 48000). 

Lets take a last example concerning these timing issues: suppose a 24 bytes sysex with a dropped F7 and a 44100 (Hz) srate. In the case of "pwe=1", the next command delta time should be 338,688. If it's rounded to the nearest value (339), again the receiver won't be able to decide wether it means a dropped F7 or an intentional delay. To avoid this ambiguity, delta time should be rounded to its integer value (338).

My general feeling is that the semantic of delta time is a little bit complex in  pwe mode. Wouldn't it be possible to use delta time for the unique purpose of expressing the sender timing intention (maybe it's a fantasy). Of course it means that an additional mechanism to code the dropped F7 is to be provided (terminating the sysex with 2 consecutive F7 for example).

> John Lazzaro writes:

(3) is certainly a good solution but (2) is a more flexible one: it allows a receiver to request a (skew-)sensitive sending procedure and let the purpose of this procedure apart.

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

---

From: Dominique Fober <[email-masked]>
Date: Wed, 13 Mar 2002 14:05:54 +0100

> Martijn Sipkema writes:
>
>I think normally the delta time should indicates the time between the
>start of the previous message and the start of the current message.
>In pwe mode a delta time of 0 would indicate a zero gap between
>the messages, i.e. the start time of the current message is the start
>time of the previous message + its transmission time. With "pwe=0"
>a delta time of 0 would mean that the messages occur simultaneously.

That's clearly said: I agree.

>I agree that terminating a sysex message with 2 consecutive 0xF7 is
>probably better than using delta times for this.