Subject: [MMUSIC] Draft MMUSIC minutes from Atlanta

From: Colin Perkins <[email-masked]>
Date: Mon, 16 Dec 2002 17:34:06 -0500

Multiparty Multimedia Session Control Working Group Minutes

Reported by Colin Perkins

   The MMUSIC working group met once at the 55th IETF meeting in Atlanta.
   We discussed SDP key management and media security descriptions, media
   format independent SDP parameters, SDP bandwidth modifiers, examples of
   the offer/answer model, Internet Media Guides, XML schema for video
   control and the revised RTSP specification.

Agenda Bashing and Status update

   The meeting started with an introduction and status report by Joerg Ott.
   The SIMCAP draft has been published as RFC 3407, and the FID draft is in 
   the RFC Editor's queue. The comedia, sdp4nat and SDPnew drafts are still
   with the IESG. The draft on reservation flows is completing its working
   group last call, and will be submitted to the IESG for publication as a
   proposed standard immediately after the meeting.

   There have been minor changes to the SDP spec, to address comments from
   the list. We are waiting for feedback from our area director before we
   can progress this further. There has been no recent update to the SDPng
   draft, but the authors are working on a new version that will have some
   internal reorganization, will focus on the offer/answer model, and will
   leave multiparty content-independent negotiation for a future extension
   document. 
   
   The SDPng Transition draft (draft-ietf-mmusic-sdpng-trans-02.txt) has
   been revised, and is largely complete. Feedback is solicited, we plan 
   to issue a working group last call shortly.

   The SDP Source Filter draft (draft-ietf-mmusic-sdp-srcfilter-02.txt)
   seems to be complete. Joerg asked if a working group last call would
   be appropriate? There were no objections, and a last call will be
   issued shortly. 

   The comedia draft is, in principle, complete but concerns have been
   raised about applicability in the presence of middle-boxes. Joerg Ott
   outlined his understanding of the issues. Jonathan Rosenberg disagreed
   with Joerg's formulation: rather the issue is that there'a a strong
   coupling between session lifetime and connection lifetime, and problems
   reusing connections. This causes too much load and bad congestion state.
   Jonathan suggested updating the comedia spec to address these concerns.
   Allison Mankin asked if this needs just a relatively small change rather
   than an elaborate extension? Jonathan expected the changes to be small.
   Joerg Ott noted that we need to understand the muxing and binding
   mechanisms. Jonathan agreed, since right now there are problems due to
   NAT, firewalls, etc. Jonathan said he would produce a concrete proposal
   on what needs to be changed in comedia "within a month", else we will go
   ahead with the existing specification.

   Joerg noted that the working group charter is out of date. The chairs
   will work on updated milestones and charter, to be circulated to the
   list for comments. Suggested new work items may include Internet Media
   Guides and Floor Control, but these need to be discussed with the area
   directors before any decision is taken.

MIKEY/Key Management with SDP

   Allison Mankin (Transport Area director) and Eric Rescorla (security
   advisor for the transport area) outlined their concerns with the key
   management model for SDP and the MIKEY draft. Eric's concern is the
   binding between MIKEY and SDP, which allows multiple key management
   protocols, such as IKE, S/MIME, etc. There is no protection against
   downgrade attacks during the protocol negotiation. 

   Elisabetta Carrara noted that there is a recommendation in the draft to
   choose between appropriate crypto-suites, but this did not satisfy Eric.
   Jonathan Rosenberg said that his understanding is that using MIKEY with 
   SDP is not sufficient, the SDP will be protected with S/MIME anyway and
   hence S/MIME provides the protection against downgrade attacks. Eric
   asked why, if you have S/MIME already, do you need MIKEY? Elisabetta
   noted that we don't commit to S/MIME, but Eric countered that, to have
   reasonable security, S/MIME or similar protection is needed in addition
   to MIKEY. Discussion continued for a while with no real resolution.
   Allison Mankin committed provide a written review of the draft, with
   detailed comments for discussion on the list.

SDP Security Descriptions for Media Streams

   Mark Baugher outlined the new draft on SDP Security Descriptions for
   Media Streams (draft-baugher-mmusic-sdpmediasec-00.txt). This is an
   alternative means of exchanging keying material, to be used when the
   SDP message is securely delivered. Accordingly it is expected to be
   complementary to key management with MIKEY. 

   Mark outlined the limitations of the existing "k=" line, described the
   proposed "a=crypto:" attribute, and outlined use with the offer/answer
   model. Jonathan Rosenberg asked unclear why you'd want to do separate
   security properties on a codec by codec basis since this seems to be the
   cause of a lot of complexity? 

   Mark asked if this could become an MMUSIC work item. The chairs agreed
   that the work is a good thing to do, but need to figure out the correct
   home for it. 

SDP attribute for qualifying Media Formats with Generic Parameters

   Flemming Andreasen presented draft-rajeshkumar-mmusic-gpmd-01.txt, the
   format independent parameter that can apply to existing MIME types. He
   outlined the background to the draft, signalling voice-band data, and
   noted issues with the current draft: it is very open-ended and needs 
   to be more limited in scope; it needs to specify interactions with the
   offer/answer model; and it needs a procedure for registration of new
   gpmd parameters. 

   Jonathan Rosenberg recommend that parameter specifications suggest the
   actual interaction with offer/anser. He also suggested that we require
   new parameters to be standards track.

A Transport Independent Bandwidth Modifier for SDP

   Magnus Westerlund outlined draft-westerlund-mmusic-sdp-bwparam-01.txt,
   on a new set of SDP bandwidth modifiers that signal session bandwidth in
   a transport independent manner. These are intended to solve problems due
   to NATs and protocol translation, that make the existing parameters less
   than useful.

   Steve Casner noted that biggest open issue is whether we really need to
   make the change at all? Magnus noted that the bandwidth can increase by
   25% with IPv6, compared with the value currently signalled, a compelling 
   argument for the new parameters. Steve disagreed, noting that the RTCP
   bandwidth doesn't have to be that accurate, and that this level of
   inaccuracy is unlikely to be problematic. He also said that a stronger
   point is bandwidth allocaton for links, where it seems likely that for
   tightly controlled channels, header compression will be used, so the
   difference between v6 and v4 goes away. 

SDP Offer Answer Examples

   Alan Johnston outlined draft-johnston-mmusic-offer-answer-examples-00.txt, 
   giving a series of examples and scenarios for the use of offer/answer.
   The group expressed interest. Joerg Ott asked that the draft be expanded
   to give some pointers to why the examples are correct.

A Framework for Internet Program Guides

   Yuji Nomura discussed draft-nomura-mmusic-pguide-framework-00.txt, a new
   framework for Internet Program Guides that has evolved out of the drafts
   that were discussed in Yokohama. There are a number of open issues: can
   this become a charter item of MMUSIC? Revision of requirements? Choice
   of protocol for announcements? Appropriate description format? 

   There was much discussion of the naming of the work, with many people
   disliking the term "Internet Program Guide". It was decided to call the
   work "Internet Media Guides" from now on.

   Joerg Ott noted that many description formats could be used, and that we
   would not want to restrict ourselves to a single format. Similarly, we
   would not want to define a new format within MMUSIC, but instead use the
   existing solutions.  

   Henning Schulzrinne asked that we take a step back to see what we learnt
   from SAP. Other things have happened in the space of event notification,
   and SAP hasn't been a clear success because of the service model, etc.
   We want to revisit, and see what we've learnt.

   The chairs noted that this work is not within the MMUSIC charter. They
   will work with the area director, to determine if MMUSIC is appropriate
   for this work, or if it should occur elsewhere.

XML Schema for Media Control

   Orit Levin outlined draft-levin-mmusic-xml-media-control-00.txt, an XML
   schema for media control. Orit noted that several alternative approaches
   have been discussed previously (CODEC specific RTP/RTCP primitives, RTCP
   feedback as for loss recovery, SDP extensions) but rejected for various
   reasons. They therefore propose the use of an XML scheme conveyed using
   a reliable protocol. The primitive commands are "picture fast update",
   "GOB fast update", "MB fast update" and a "picture freeze" command. This
   is encapsulated in the SIP INFO method, and next steps are to define the
   encapsulation.

   Steve Casner noted that he is sure an XML schema can be defined for this
   purpose. A more critical question might be how it is transported, and if
   the result will work. Rohan Mahey noted "if I could go back in time and
   undo INFO, so it didn't exist, I'd be very happy". He noted the issue is
   that this is media oriented, and should be sent with the media. Asked if
   some form of RTCP based approach might be more appropriate?

   Henning Schulzrinne expressed concern about re-inventing SOAP on the
   sly. Besides asking whether this belongs in SIP or not, we don't need
   yet another RPC protocol. If it is an RPC mechanism we should ask how
   we can make exisitng RPC solutions work in this context? He also asked
   if there is a need for a traditionally reliable mechanism, and how it 
   relates to other work on, for example, floor control?

   Nermeen Ishmail noted that there is a real problem of using SIP, since
   if you lose the control path, you lose the media. This leads towards
   using RTCP, but there is an interoperability problem with that since
   H.323 systems convey this information in the control path. Accordingly,
   we should steer away from RTCP, and use a media control protocol. There
   was concern that this would not work either, due to the latency of the
   control channel.

   Jonathan Rosenberg noted that this might be a perfect candidate for a
   SOAP protocol, signalled in SDP? Henning agreed that SOAP works today, 
   but there is a need for a way of associating SOAP connections with a
   media stream, in SDP. Orit asked where should we do SOAP work, since
   it is unclear if MMUSIC is the appropriate forum? The answer seems to
   depend on the form of the final solution.

RTSP Update

   Magnus Westerlund outlined recent changes to the revised RTSP draft
   (draft-ietf-mmusic-rfc2236bis-02.txt) and gave a pointer to the bug
   tracker at http://rtspspec.sourceforge.net/. He asked for the group 
   to review the updated specification, and noted that teleconferences
   to discuss changes will resume shortly. He also outlined major open
   issues.

   This first open issue is redirect: shall the server be allowed to
   close a session as soon as the clients ACKs the REDIRECT? And what
   should be done with the 3xx codes? 

   Magnus noted that the authors are lacking experience with RECORD. It
   seems that the spec needs significant clarifixation on how to use it,
   and that there are many open issues. Input was requested from someone
   who has implemented RECORD, otherwise the authors proposed to remove it
   from the base specification (leaving it as an extension document). Steve
   Casner said he was pretty sure that IP/TV used RECORD, and that this may
   provide implementation experience? Rob Lanphier explained that we need
   people to document what they're doing with RECORD, not just to list
   implementations. Henning Schulzrinne asked if the issues with RECORD
   might be somewhat similar to WEBDAV style protocols, and if experience
   in that field may be helpful? 

   Other open issues exist with Appendix C, the Accept-Ranges header, the
   Via header, Negative Scale, TLS support, RTSP over UDP, etc. A bar BOF
   was scheduled for later in the week to discuss these, and discussion
   will continue via the mailing list and teleconferences.

				   - * -

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Ross Finlayson <[email-masked]>
Date: Mon, 16 Dec 2002 14:44:02 -0800

>    be appropriate? There were no objections, and a last call will be

On the mailing list, Magnus Westerlund made some useful 
comments/suggestions about this draft.  So, I'd like to submit a new, 
revised version (hopefully soon), and give the WG time to look it over, 
before it goes to last call

         Ross.

---

From: Colin Perkins <[email-masked]>
Date: Mon, 16 Dec 2002 18:34:36 -0500

>before it goes to last call

Okay.

Colin

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 17 Dec 2002 11:26:51 +0100

Hi Colin,

I have one comment on the reporting of below item:

>   difference between v6 and v4 goes away. 
To my understanding Steve did not comment on the general usefulness of the attribute, only the RTCP part. I have thought about it a bit and think I can satisfy with a note in the draft explaining the RTCP issue and what normal cost will be and that it is normally not significant enough to warrant any fix. 

Some numbers and explanation on how the RTCP bandwidth and fairness is affected by transition between IPv4 and IPv6. 

Worst Case:
The worst case is a large group where a single user sits on a IPv6 network and all other participants uses IPv4. In this case when the number of participants increase towards infinity the bandwidth share coming from IPv4 network will become 1.0. In this case the bandwidth will increase with the IPv6 overhead compared to IPv4 times the number of packets. The number of packets is depending on the RTCP packet size. The smallest possible RTCP packet including IPv4/UDP overhead is 46 bytes which is a correctly formed with RR and SDES CNAME, but information wise an empty packet. With a full utilization of the assigned bandwidth the increase in overhead is 20/46 = 43.5%. A bit more realistic RTCP packet with a useful CNAME tag of 14 chars and a Receiver Report the packet size for IPv4/UDP/RTCP is 80 bytes. A 80 byte packet gives the 25% increase in RTCP bandwidth. The larger the average RTCP packet becomes ,the less effect on the total bandwidth the IPv6 overhead has. For a 120 byt!
es packet the increase in bandwidth has dropped to 20/120 = 16.7%

A common unicast case:
In the case of two sources communicating with unicast between a IPv4 and a IPv6 domain the number becomes different. The packet size from above still applies but the communication frequencies are different. In this case only half of the RTCP bandwidth is assigned to the IPv4 located participant. Also in cases with at least moderate session bandwidths the participants will not full utilize it unless the minimum interval rule of 5 second is removed. All this given that the bandwidth is used fully the increase on the IPv6 side will be 21.75% for minimal packets. For more realistic packets its only at most a 12.5% increase.

Summary of increase on IPv6 side:

		Packet sizes
Communication | Worst case    Realistic
--------------|-------------------------
Worst Case    |  43.5 %       21.75 %
Unicast       |  25 %         12.5 %

Fairness:
The fairness seen over longer time is that a IPv6 host will send avg_rtcp_size/(20+avg_rtcp_size) as often as the IPv4 host. On a short time scale this will not become evident due to the 0.5 wide randomization of sending intervals.

The fairness factor for different sizes is:
avg_rtcp_size   Fairness
46              0.70
80              0.8
120             0.86

Conclusion:
Seen from the above figures an IPv6 host can in absolute worst case get a 44% increase, i.e. compared to a session with 5% RTCP bandwidth the total session bandwidth increase will be 2.1 %. In a more realistic case the figures would result in 0.6% increase. This is rather marginal compared both to variations in media bitstream rate and what the RTCP randomization rule can result in. 

-- 

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

---

From: Stephen Casner <[email-masked]>
Date: Tue, 17 Dec 2002 13:08:26 -0800 (PST)

Magnus,

> To my understanding Steve did not comment on the general usefulness
> of the attribute, only the RTCP part. I have thought about it a bit
> and think I can satisfy with a note in the draft explaining the RTCP
> issue and what normal cost will be and that it is normally not
> significant enough to warrant any fix.

Well, actually I was questioning whether the mechanisms in this draft
are needed, but you are right that this was primarily based on whether
RTCP required it.

I concede that there is a problem when the sender specifies the
session bandwidth making one assumption about underlying protocols and
the receiver, which may be using different underlying protocols, is
the one that does the bandwidth reservation (as in RSVP).  On the
other hand, your proposal relies on multiple SDP attributes which are
optional and/or ignorable.  I wonder whether, in practice, fudge
factors will be used instead.

What happens when the RSVP reservation made on an IPv4 net reaches the
NAT translating to an IPv6 net?  The extra SDP parameters won't be
available to the NAT.

                                                        -- Steve

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 18 Dec 2002 13:53:59 +0100

Hi Steve,

My reply below:

>factors will be used instead.

I can at least clarify why I see this work as important. In UMTS 
wireless networks, a terminal will be required to set up radio bearers 
to achieve packet transport with desired behavior. A radio bear has a 
number of parameters that effects it behavior and which can be tailored 
to the application. Two such parameters, which are very important are 
guaranteed and maximum bitrate. These values will be followed by the 
network as long it can maintain them. If the network can't keep up the 
guaranteed bitrate it will renegotiate the radio bearer. It will also 
filter any traffic exceeding the maximum bitrate. As a user pay for the 
radio resources associated with a certain bearer the user desires to 
utilize the bearer as well as possible. Therefore it is important to 
know the maximum bitrate of the stream. If a media stream is larger than 
the maximum bitrate the radio network can offer there is no reason to 
set up the flow at all. So there is desire to know the bitrate with 
fairly high accuracy. I am convinced that the difference bitrate between 
a media stream over IPv4 and IPv6 is significant enough.

Some examples:
AMR conversational media stream:
Max packet rate: 50
Difference in bitrate between IPv4 and IPv6: 8000 bits/s

AMR streaming media stream:
Max packet rate: 10
Difference in bitrate between IPv4 and IPv6: 1600 bits/s

Low bitrate video stream 12,5 Hz frame rate:
Max packet rate: 15
Difference in bitrate between IPv4 and IPv6: 2400 bits/s

These differences are significant if we are talking about streams which 
maximum bitrate are 32 or 64 kbps. A streaming application with AMR and 
low bitrate video with streams tailored to 32 kbps using IPv4, will not 
fit if using IPv6 as the increase overhead will be approximate 4000 
bits/s, which is a 9.4 % increase.

Another valid use case is a modem link which you know have header 
compression. In this case you can calculate how much more media traffic 
you would possibly be able to accommodate. Of course you will need some 
fudge factor here as you don't know how close to maximum packet rate the 
stream utilize.

>NAT translating to an IPv6 net?  The extra SDP parameters won't be

I would say that this is for further improvements of resource 
reservation signaling to consider the transition case. Without having 
any data at all it is at least impossible to fix it.

-- 

Magnus Westerlund

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 24 Dec 2002 17:01:10 +0100 (MET)

Hi.

> before it goes to last call

I have two comments (or questions?).

1. specification of multiple source addresses

It should be possible to specify more than two source addresses per
channel, let's say, (INCLUDE, {S1,S2}, G1). We can imagine something
like a "panel session". In this case, more than two senderes
(speakers) may exist in the session. In section 2.2.4, there is a
description about multiple sources, but I think this mentions about
"multiple channels", not "multiple senders per channel". Am I correct?
If I'm correct, statements, "... single unicast sender address ...",
in 2.2.1 should be changed to "... single or multiple unicast sender
address(es) ...". And if we can specify multiple sources for single
channel, then section 2.2.4 should be also modified to clarify the
differences.

2. specification of EXCLUDE mode?

Although I don't have a strong objection, I'd like to ask you, "Is it
really needed to have a capability to specify EXCLUDE mode in an SDP?".
I mean, I cannot imagine why we need to announce EXCLUDE source
(sources?) to SDP clients. What is the purpose? And what kind of
application or service uses the information?
I prefer hearing "please join ({S1,S2},G1)", rather than "please
don't join (Sx,G1)".

From MSF basis, EXCLUDE mode would be set up by each end-node. 
What is the situation that SDP makes *all* end-nodes stop receiving
data coming from Sx, when a session is announced?
Moreover, the I-D only says "Unicast Exclusion Example". An EXCLUDE
mode specified in this draft is only useful in unicast communication?
If so, could you explain the benefit (or reason)? (I cannot understand
the necessity of section 2.2.2.)
I'm just curious about EXCLUDE mode specification within an SDP.

Thanks.
--
Hitoshi Asaeda

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 24 Dec 2002 17:53:20 +0100 (MET)

> I have two comments (or questions?).

Oh, I'm sorry. (I cut too many parts from original mail.)
My comments are for draft-ietf-mmusic-sdp-srcfilter-02.

Happy holidays.