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

> 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
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt