Subject: [MMUSIC] Simulcast: Bandwidth handling

From: Harald Alvestrand <[email-masked]>
Date: Fri, 20 Mar 2015 13:38:12 +0100

I have now read through draft-ietf-mmusic-sdp-simulcast, and tried to 
figure out how it does bandwidth-differentiated streams.

The answer seems to be that it ducks the issue.

The introduction clearly indicates that bandwidth is one of the 
characteristics that one is interested in controlling.

The requirements section (4) talks about "detailing the 
characteristics", without defining which characteristics it's talking about.

The "a=simulcast" line does not indicate any bandwidth.

The examples use H264 with a "max-mbps" parameter - but this is part of 
the codec specific "a=fmtp" parameter, it's not something that can be 
used for any other codec.

There are a number of troubling aspects here:

- The use of PT to distinguish between simulcast layers indicates that 
one will have to consume a large
number of payload types - especially when also using PT to distinguish 
between alternative formats.
This ship has probably sailed, though - the binding to the a=imageattr, 
which is also payload-type linked, means that we're already committed to 
paying this cost.

- The non-explicit bandwidth handling means that changing the video 
bandwidth for a stream will require adding new payload type numbers 
(since one cannot easily retire the old ones) - again increasing 
pressure on the payload type pool.

- The use of a=fmtp to give the basis for bandwidth restrictions / 
guarantees means that one is either imposing rules on the registration 
of new (and old!) payload types, or that one requires codec-specific 
code in the senders and receivers in order to handle layers of differing 
bandwidth.

If, within one media description, it is desired to express 
per-payload-type bandwidth restrictions or guarantees, this would be 
done much more cleanly with a new attribute:

a=pt-bandwidth:97 send 1024 recv 2048

Yours for a more orthogonal set of attributes

        Harald Alvestrand

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Fri, 20 Mar 2015 16:40:18 +0000

Hi Harald,

The a=simulcast attribute only expresses what formats will be sent
concurrently. It does not express anything about the formats themselves,
and expects other attributes to express this.

Earlier draft versions included deep expression of formats, using either
new attributes or capneg, trying to encompass every aspect of various
formats that may be relevant to simulcast, including bandwidth/bitrate.
The WG feedback was this was too complex.

The current version simplifies simulcast to express only what formats will
be sent concurrently. This simplification does not come for free, as you
observed. It pushes the complexity of expressing different formats to
other attributes. There was quite a bit of discussion on this specific
design point in the room before the call for adoption. The conclusion was
to limit simulcast to express concurrency while other attributes express
different formats and their configurations, using PT as the binding for
different formats/configurations.

Your concern about exhausting PTs by hanging all format expression on PT
was raised, and is valid. A general solution to the PT exhaustion problem,
independent of simulcast, is proposed in draft-pthatcher-avtext-esid-00 in
the avtext agenda.

Your proposed bandwidth attribute works fine with the current simulcast
attribute, because you are using PT bindings. It will not be in scope for
the current draft, given the scope described above, but it could be done
in a separate draft that is completely compatible with the current
simulcast work.

Cheers,
Mo

On 3/20/15, 8:38 AM, Harald Alvestrand <[email-masked]> wrote:

The requirements section (4) talks about "detailing the
characteristics", without defining which characteristics it's talking
about.

        Harald Alvestrand

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 21 Mar 2015 12:01:26 +0100

> in a separate draft that is completely compatible with the current

Thank you for the acknowledgement of my points.

I don't see a compelling case for me personally to pursue the per-PT
bandwidth limit attribute at the moment, but will keep this in mind if
other discussions make this more critical.

Harald

---

From: "Mo Zanaty (mzanaty)" <[email-masked]>
Date: Sat, 21 Mar 2015 13:18:20 +0000

Note there was an earlier (expired) draft on this, including the important point you raise of asymmetric bandwidth in send/recv directions. 

https://tools.ietf.org/html/draft-westerlund-mmusic-sdp-bw-attribute-02

Mo

> On Mar 21, 2015, at 7:01 AM, Harald Alvestrand <[email-masked]> wrote:
>