Subject: Re: [AVT] AVT draft agenda

From: lazzaro <[email-masked]>
Date: Tue, 24 Oct 2006 07:42:49 -0700

Hi everyone,

On Oct 24, 2006, at 6:48 AM, Roni Eveb wrote:

> See the following draft agenda. If I forgot someone please let me know

[...]

> 10:10   RTP & layer 2 QoS                                    
> (Teener, 10)

Is there a document coming for this?  If not, could the speaker say
a few words on list to provide some details?  Thanks, sorry if there's
been a discussion already and I didn't see it ...

---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---

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

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Wed, 25 Oct 2006 08:09:09 -0400

Here's the background that Michael gave us:

Background:

  I¹m the chair of the IEEE 802.1 Audio/Video Bridging Task Group
  (see http://www.ieee802.org/1/pages/avbridges.html  and the older
  one for Residential Ethernet at http://www.ieee802.org/3/
  re_study.html). We¹ve been given the job of bringing QoS
  appropriate for A/V applications into 802 networks, starting with
  Ethernet and quickly adding 802.11 and 802.16. By far most of our
  work will be in the bridges where we will have three major
  enhancements:

  Precise time synchronization so that every network element will
  have access to a very high quality clock (done via a layer 2
  profile of the new revision of IEEE 1588). This is being done as
  project 802.1AS, and it¹s well on its way.
  An admission control protocol that allows an endpoint to
  communicate its QoS requirements for a particular stream to all the
  network elements between the source and the sink. This is currently
  called the ³Stream Reservation Protocol² and will be done as
  project 802.1at. This is a gross simplification of the kind of
  thing done in RSVP (it¹s only 1:n, only specifies two different
  traffic classes, etc., etc.).
  A traffic regulation/forwarding/queuing specification for the
  streams set up by SRP that defines how the appropriate frames are
  filtered/tagged/queued inside bridges, and the nature of the
  traffic shaping required by the transmitter. This will be done as
  project 802.1av (clever, eh?).

  I personally think that the primary internet layer for these
  services will be RTP and its related family of specifications, but
  I¹m no expert, and I¹d feel really uncomfortable if there isn¹t a
  fairly intense level of interaction between the RTP community and
  our TG.

  I wonder if you could help us get that process started? Is there
  some venue that we could present what we have done so far and our
  intent for the future?

---

From: "Greg Herlein" <[email-masked]>
Date: Wed, 25 Oct 2006 19:51:38 -0700

I missed the original post but am highly interested in this discussion
and standard solution.  My application for this involves several
displays playing the same multicast stream and having the desire to
syncronize the playback of those streams to the frame level to the
maximum extent possible.  Variations in transit time and jitter buffer
processing will make this difficult without some kind of
syncronization.  Having a clock on the wire would solve part of this.

I'd welcome a link to more information on efforts underway.

Greg

On 10/25/06, Randell Jesup <[email-masked]> wrote:
> "Tom-PT Taylor" <[email-masked]> writes:
> Just wondering: why is precise synchronization important?  Especially since
> sync will drift.  And why do the network elements need to know?  Perhaps
> you're trying to instill knowledge into the network of how long a packet
> has been "in-transit"?
>
> RTP provides for a higher-level end-to-end synchronization on a per-stream
> level (RTCP and NTP), though for reasons having to do with its origin in
> multicast scenarios synchronization can take a short while.  (There are
> ways around that like AVPF).  Is there a reason this part of the problem
> couldn't be addressed by protocol modifications at that level?
>
> --
> Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
> [email-masked]
>
>

---

From: Randell Jesup <[email-masked]>
Date: Thu, 26 Oct 2006 09:54:08 -0400

>syncronization.  Having a clock on the wire would solve part of this.

That's much more of a higher-level issue IMHO.  Synchronization based on
transit and jitter buffer time is an application issue.  Synchronizing
clocks can be done now using NTP and the like; once you have synchronized
clocks you can build a synchronized display on top of that. RTCP (or in
theory signalling) can let you know the NTP time at the sender for each RTP
timestamp.  A clock on the wire doesn't solve the application-level issues;
it seems to be at most a replacement for (local) NTP.  If there's a strong
need for a local-network NTP replacement or alternative, that should be
done within that context, and allow LAN nodes to be dumb whenever
possible.  But I'm just guessing without seeing the rationale for this
proposal.

Some level of coordination is required if the jitter buffers aren't of a
static depth, and/or providing at the session level some sort of indication
of how long after sampling every display is to show the frame (say evey
display will show a frame 150ms after it was captured).  That effectively
gives you a maximum delay in transit; if it doesn't make it there in time
you skip it.  In this case, the buffer is really not a "jitter buffer" per
se.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)