Subject: [MMUSIC] Mirja Kühlewind's No Objection on draft-ietf-mmusic-sdp-simulcast-12: (with COMMENT)

From: Mirja Kühlewind <[email-masked]>
Date: Mon, 18 Jun 2018 07:02:11 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-mmusic-sdp-simulcast-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-simulcast/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Two smallish comments/questions:

1) Maybe section 3 could/should also mention that sending multiple stream
simultaneously from the source to a mixer has also the disadvantage of
consuming more network resources..?

2) The intro says:
"The media transport topologies considered are point to point RTP sessions as
well as centralized multi-party RTP sessions..." but then only middlebox
scenarios are discussed and I actually cannot really imagine where a
point-to-point scenario makes sense. Could you clarify…?

---

From: Bo Burman <[email-masked]>
Date: Wed, 20 Jun 2018 12:50:53 +0000

Hi Mirja,

Thank you for your comments! Please find responses below.

/Bo
(as individual author)

> -----Original Message-----
> From: Mirja Kühlewind <[email-masked]>
> Sent: den 18 juni 2018 16:02
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: Mirja Kühlewind's No Objection on draft-ietf-mmusic-sdp-simulcast-12: (with COMMENT)
> 
> When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines.
> (Feel free to cut this introductory paragraph, however.)
> 
> 
> 1) Maybe section 3 could/should also mention that sending multiple stream simultaneously from the source to a mixer
> has also the disadvantage of consuming more network resources..?
[BoB] No problem. I'll add that.

> 
> 2) The intro says:
> "The media transport topologies considered are point to point RTP sessions as well as centralized multi-party RTP
> sessions..." but then only middlebox scenarios are discussed and I actually cannot really imagine where a point-to-point
> scenario makes sense. Could you clarify…?
[BoB] I believe the most relevant point-to-point case for simulcast would be when establishing a point-to-point session between simulcast-capable middleboxes, where end-users for the entire conference are distributed among those middle-boxes. That is already hinted in the introduction by "... and middleboxes may further distribute the simulcast streams to other middleboxes...", but I can agree it is probably not obvious that this can be achieved with a point-to-point simulcast session between middleboxes.

---

From: Bo Burman <[email-masked]>
Date: Tue, 26 Jun 2018 07:31:05 +0000

Hi Mirja,

Would these additions work to address your comments, based on my explanation below?

Your first comment, in section 3:

OLD:

   o  Switching a subset of all received RTP streams or sub-streams to

      each receiving participant, where the used subset is typically

      specific to each receiving participant.  The main advantages of

      this approach are that it is computationally cheap to the RTP

      Mixer, has very limited impact on media QoE, and does not require

      RTP Mixer (full) access to media content.  The main disadvantage

      is that it can be difficult to combine a subset of received RTP

      streams into a perfect fit to the resource situation of a

      receiving participant.

NEW:

   o  Switching a subset of all received RTP streams or sub-streams to

      each receiving participant, where the used subset is typically

      specific to each receiving participant.  The main advantages of

      this approach are that it is computationally cheap to the RTP

      Mixer, has very limited impact on media QoE, and does not require

      RTP Mixer (full) access to media content.  The main disadvantage

      is that it can be difficult to combine a subset of received RTP

      streams into a perfect fit to the resource situation of a

      receiving participant.  It is also a disadvantage that sending

      multiple RTP streams consumes more network resources from the

      sending participant to the RTP Mixer.

Your second comment, in introduction:

OLD:

   …transport over RTP.  The media transport topologies considered are

   point to point RTP sessions as well as centralized multi-party RTP

   sessions, where a media sender will provide the simulcasted streams

   to an RTP middlebox or endpoint, and middleboxes may further

   distribute the simulcast streams to other middleboxes or endpoints.

   Usage of multicast or broadcast transport is out of scope and left

   for future extension.

NEW:

   …transport over RTP.  The media transport topologies considered are

   point to point RTP sessions as well as centralized multi-party RTP

   sessions, where a media sender will provide the simulcasted streams

   to an RTP middlebox or endpoint, and middleboxes may further

   distribute the simulcast streams to other middleboxes or endpoints.

   Simulcast could, as part of a distributed multi-party scenario, be

   used point-to-point between middleboxes.  Usage of multicast or

   broadcast transport is out of scope and left for future extensions.

/Bo

(as individual)

> From: Bo Burman <[email-masked]>

> Sent: den 20 juni 2018 14:51

> To: Mirja Kühlewind <[email-masked]>; The IESG <[email-masked]>

> Subject: RE: Mirja Kühlewind's No Objection on draft-ietf-mmusic-sdp-simulcast-12: (with COMMENT)

> > From: Mirja Kühlewind <[email-masked]<mailto:[email-masked]>>

> > To: The IESG <[email-masked]<mailto:[email-masked]>>

> > Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;

> > [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

> > Subject: Mirja Kühlewind's No Objection on

> > draft-ietf-mmusic-sdp-simulcast-12: (with COMMENT)

> > Please refer to

> > https://www.ietf.org/iesg/statement/discuss-criteria.html

> > 1) Maybe section 3 could/should also mention that sending multiple

> > stream simultaneously from the source to a mixer has also the disadvantage of consuming more network resources..?

> > "The media transport topologies considered are point to point RTP

> > sessions as well as centralized multi-party RTP sessions..." but then

> > only middlebox scenarios are discussed and I actually cannot really imagine where a point-to-point scenario makes

> sense. Could you clarify…?

> [BoB] I believe the most relevant point-to-point case for simulcast would be when establishing a point-to-point session

> between simulcast-capable middleboxes, where end-users for the entire conference are distributed among those

> middle-boxes. That is already hinted in the introduction by "... and middleboxes may further distribute the simulcast

> streams to other middleboxes...", but I can agree it is probably not obvious that this can be achieved with a point-to-

> point simulcast session between middleboxes.

---

From: "Roni Even (A)" <[email-masked]>
Date: Wed, 27 Jun 2018 06:29:16 +0000

Hi Bo,
On section 3 , maybe this is a good reason for mandating support of pause/resume [RFC7728] in simulcast.
Roni

From: mmusic [mailto:[email-masked]] On Behalf Of Bo Burman
Sent: Tuesday, June 26, 2018 10:31 AM
To: Mirja Kühlewind; The IESG
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [MMUSIC] Mirja Kühlewind's No Objection on draft-ietf-mmusic-sdp-simulcast-12: (with COMMENT)

Hi Mirja,

OLD:

      receiving participant.

NEW:

OLD:

   for future extension.

NEW:

/Bo

(as individual)

> From: Bo Burman <[email-masked]<mailto:[email-masked]>>

> To: Mirja Kühlewind <[email-masked]<mailto:[email-masked]>>; The IESG <[email-masked]<mailto:[email-masked]>>

> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>