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

[Bo Burman <[e-mail]>]

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)



> -----Original Message-----

> From: Bo Burman <[e-mail]>

> Sent: den 20 juni 2018 14:51

> To: Mirja Kühlewind <[e-mail]>; The IESG <[e-mail]>

> Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]

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

>

> Hi Mirja,

>

> Thank you for your comments! Please find responses below.

>

> /Bo

> (as individual author)

>

> > -----Original Message-----

> > From: Mirja Kühlewind <[e-mail]<mailto:[e-mail]>>

> > Sent: den 18 juni 2018 16:02

> > To: The IESG <[e-mail]<mailto:[e-mail]>>

> > Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;

> > [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>

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

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

> >

> > 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..?

> [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.