[sdiy] ADDA & MIDI over Ethernet/Firewire?

[Magnus Danielson]

From: Tom May <tom at tommay.net>
Subject: Re: [sdiy] ADDA & MIDI over Ethernet/Firewire?
Date: 10 Jun 2003 16:09:51 -0700

> Magnus Danielson <cfmd at swipnet.se> writes:
> 
> > Anyone who still states that Ethernet or "IP" (we old farts say TCP/IP) is
> > "simple" haven't looked at the stacks of specs they make. They are also not
> > "simple" to fully comprehend and understand, and this is especially true when
> > it comes to the issues which they are really bad at telling.
> 
> Then forget TCP.  As you said "Loss of a single real-time traffic
> packet is a catastroph and you might as well give up after that since
> you no longer is able to do anything usefull".  All of the
> complication and gotchas of TCP is dealing with lost packets and
> packets arriving out of order (ok, and a few other things you don't
> care about for MIDI).  Spec the layers below the protocol so packets
> (ethernet frames, UDP, whatever) will arrive, will arrive in order,
> and will even arrive in a timely manner.  Call anything that violates
> this broken, and fix, replace, or live with it.  Seems to me this is
> pretty much how MIDI works now.

You are technically correct that TCP is not to be used, but in the old days did
TCP/IP refer to the whole suite of protocols, where as today it is only refered
to as IP.

The "slow-start" (exponential!) of TCP is a very important thing for an
internet like Internet but might not be as usefull for local stuff like we are
talking about.

When you use RTP you are using UDP and not TCP BTW, which makes sense. This is
however one of the annoying things since none of the flow-control stuff of TCP
can be applied on the UDP traffic and it can't behave "decent" and backoff it
is often argued. When doing real-time traffic there is not the option of
backing off, either you get the whole stream there on time or you don't.

RTP adds the necessary re-ordering overhead, time stamps for propper playback
and standardised encoding-schemes of stuff like MPEG-2, JPEG, H.261, G.711 etc.

However, there is no magic which RTP (or any other wrapper protocol) can play
to deal with the stream-collisions in the IP or Ethernet switching and the
related queue-delays and packet-drops. This is really where the problem is, not
the way it is wrapped. Tossing every conceivable stream into one queue or line
without propper attention gives us the current scenario. You need to keep
things which is real-time dependent totally separate. Preferably in TDM (or
other similar isolations like FDM, WDM and CDM) all the way in order to ensure
best "quality of service" (which is just a set of measurements of the
_acheived_ quality of service from some transport network). Microscopic
statistical multiplexing (or statistical division multiplexing - SDM) works
well for non-realtime sensitive traffic and where re-transmission may be
acceptable. TDM, FDM, WDM and CDM uses a more macroscopic form of statistical
multiplexing, but the microscopic multiplexing gives total isolation.

The problem is that first people have developed a system for one type of
service (aka best effort) and then they try to add new services on top of this
infrastructure, it is just that these new services have totally different
requirements and thus require totally different transport solutions.

The most economic solution is to provide a TDM/FDM/WDM/CDM core solution and
provide an overlay network for various SDM traffic. Anything else will be hard
to understand and very complex (i.e. practically impossible) to engineer.

Cheers,
Magnus