Subject: RE: [MMUSIC] And one more SDP-quiz question on protocol IDs

From: [email-masked]
Date: Thu, 29 Apr 2004 14:15:30 +0300

...and...

I prefer FLUTE/UDP as to protocol ID too, but am keeping an open mind for now.

Cheers, Rod.

> -----Original Message-----
> From: ext Magnus Westerlund [mailto:[email-masked]]
> Sent: Thursday, April 29, 2004 10:33 AM
> To: Walsh Rod (Nokia-NRC/Tampere)
> Cc: [email-masked]
> Subject: Re: [MMUSIC] And one more SDP-quiz question on protocol IDs
> 
> 
> Hi Rod,
> 
> A few comments,
> 
> first it is RTP/AVP or RTP/SAVP, and in the near future also RTP/AVPF 
> and RTP/SAVPF. I assume it was only a typo.
> 
> Personally I prefer FLUTE/UDP, which seems to be the more 
> clear that the 
> main protocol information is FLUTE, which in this case is transported 
> over UDP. If anyone has another transport FOO that will work 
> for FLUTE 
> then they can specify FLUTE/FOO.
> 
> I don't think that using "data" as media type is appropriate at all. 
> Although RFC 2327 mentions data I don't think it is 
> appropriate at the 
> current state. The media types that really is used to my knowledge is 
> the ones using the names registered for MIME. See:
> http://www.iana.org/assignments/media-types/index.html
> 
> If one looks at draft-ietf-mmusic-sdp-new-15.txt the 
> following paragraph 
> is present:
> 
> "9.2.1 Media types ("media")
> 
>     The set of media types is intended to be small and SHOULD NOT be
>     extended except under rare circumstances.  The same rules should
>     apply for media names as for top-level MIME content 
> types, and where
>     possible the same name should be registered for SDP as 
> for MIME.  For
>     media other than existing MIME top-level content types, a
>     standards-track RFC MUST be produced for a new top-level 
> content type
>     to be registered, and the registration MUST provide good
>     justification why no existing media name is appropriate (the
>     "Standards Action" policy of RFC 2434 [5]."
> 
> In this respect I think that "application" is suitable for FLUTE. Can 
> you please further motivate why data would be the right choice?
> 
> To avoid further confusion I am of the opinion that 
> draft-ietf-sdp-new 
> should be updated to move all unregistered media types into a 
> note like:
> 
> Note: RFC 2326 mentions the media types "data" and "control", 
> these are 
> unregistered media types and should not be used. If these media types 
> are deemed suitable in the future, they should be registered in 
> accordance with section 9.2.1.
> 
> Cheers
> 
> Magnus
> 
> 
> [email-masked] wrote:
> 
> > One of the implications of wanting an SDP description for 
> FLUTE (previous email) is that we will need a protocol ID for 
> the m line. Although this seems trivial to me, I would like 
> to know if anyone has any great objections to "UDP/FLUTE" 
> style? ("RTP/AVT", "udp" and "TCP" are existing examples)
> > 
> > So for example, you'd get an media field looking like this:
> >    m=data 12345 UDP/FLUTE 0 
> > 
> > (Any reason not to prefer "FLUTE/UDP"?)
> > 
> > Cheers, Rod.
> > 
> > _______________________________________________
> > mmusic mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/mmusic
> > 
> 
> -- 
> 
> Magnus Westerlund
> 
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]
> 
> 

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

---

From: [email-masked]
Date: Fri, 30 Apr 2004 12:39:49 +0300

> ... Therefore use the "application" media 
> type. Then the application itself is identified in the FMT 
> part of the 
> m= line. 
>> How does that sound?

Sounds good.

Naturally, the FMT could be "null" to indicate that the application is going to need some other means to work out session content types (e.g. FDT, "IMG service description", etc.) 

> A registry for applications is then established so 
> that one can 
> determine the application. And it is the applications that 
> defines what 
> type of files are actually sent within the FLUTE delivery session.
> 
> How does that sound?

Sounds like I need to be educated about how to deal with these registrations :)

Cheers, Rod.

---

From: [email-masked]
Date: Fri, 30 Apr 2004 13:00:02 +0300

> It's beginning to sound like "m=data 49000 FLUTE/UDP" would be the 
> right way to go, letting the application pick up the media types from 
> the FLUTE session.

Sounds good. My lack of preference over application and data should be pretty clear now :)

I see that in the case of a data carousel kind of application (which user application request files from locally) "data" fits well. And in the media player application (where the player also includes the FLUTE protocol, as many already have HTTP/html) then "applciation" fits. Since these are receiver specific and since, in some situations, the sender may not have a good idea in advance that all receiver applications are of a certain sort - coming down hard on either only data or only application may be ticky. As far as I see "application" is great for my main use cases, but I suspect this may not be true of everyone.

> Unfortunately, though, the <fmt> parameter is mandatory in SDP "m=" 
> lines. Unless there is something specific to FLUTE that could 
> be used, 
> we might need a dummy value?

Makes sense "dummy" = "null".

Cheers, Rod.

---

From: [email-masked]
Date: Fri, 30 Apr 2004 14:05:09 +0300

Hi Steve

Thanks for the comment. I understand both arguments and am pretty sure either of FLUTE/UDP and UDP/FLUTE would do the job nicely

UDP/FLUTE seems closer to the RTP/AVP precedent. (Anyone know if there was a big-endian motivation behind this selection for SDP in the first place?)

FLUTE/UDP seems to show the right emphasis: FLUTE. For The receiver and application capability, the client is primarily concerned that it is using FLUTE (UDP or foo follows after that). This is also true for RTP/AVP, clients are first interested in RTP, then UDP and AVP comes next (since I've never implemented an RTP client, please put me straight if I blundered on this).

As long as we choose one, and not both ways, then I'm happy.

The reason for not just suggesting FLUTE (without the /UDP) is the potential for some theoretical future FLUTE to work over other than UDP (LCT and ALC bind us to UDP for now, but make it clear that this may not always be the case). Although FLUTE/TCP (foo/FLUTE, FLUTE/foo etc) would be contrary to the current LCT, it should not cause problems for FLUTE alone (FLUTE/TCP seems to fit into "congestion control scenario (c)" of §4 as TCP would provide the CC which is "no more aggressive than TCP" :) I think this is more a discussion for LCT transition to PS (or LCTv2) in RMT, so let me put the lid back on that can of worms for now.

Cheers, Rod.

> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Stephen Casner
> Sent: Thursday, April 29, 2004 6:23 PM
> On Wed, 28 Apr 2004 [email-masked] wrote:
> 
> > One of the implications of wanting an SDP description for FLUTE
> > (previous email) is that we will need a protocol ID for the m
> > line. Although this seems trivial to me, I would like to know if
> > anyone has any great objections to "UDP/FLUTE" style? ("RTP/AVT",
> > "udp" and "TCP" are existing examples)
> >
> The order of RTP/AVP is the order of decreasing significance.  That
> is, AVP is a particular specialization (profile) of RTP.  There are
> multiple second components that follow the first, but it is unlikely
> that the symbol "AVP" will follow anything other than "RTP" and still
> have the same meaning.
> 
> In the case of UDP and FLUTE, FLUTE is one of several protocols that
> can be layered after UDP in the packet.  FLUTE is a specialization of
> the use of UDP.  So I prefer UDP/FLUTE.
> 
> (I also prefer IP/TCP, because it reflects layering order, but the
> common terminology is TCP/IP because TCP is considered layered "over"
> IP.  I suppose this is another big-endian / little-endian issue.)
> 
> Note that in the case of "RTP/AVP", the use of UDP is implied.  To use
> RTP over another lower-layer protocol requires a new term, such as
> DCCP/RTP/AVP.
> 
> If FLUTE would only be used with UDP in this context, then UDP could
> be implicit for FLUTE as well.
> 
>                                                         -- Steve
>