Re: [MMUSIC] I-D Action:draft-ietf-mmusic-qos-identification-03.txt

["Ingemar Johansson S" <[e-mail]>]

Hi

I would say that it is possible to use SDPCapNeg even though I don't
really see any big use for involving it.

Anyway..a simple example would look like

m=video 54320 RTP/AVP 0
a=tcap:1 RTP/AVPF RTP/AVP
a=acap:1 qos-mech-send: rsvp nsis
a=acap:2 qos-mech-recv: rsvp nsis
a=pcfg:1 t=2|1 a=1,2

The SDP answer may look like 
m=video 54320 RTP/AVPF 0
a=qos-mech-send: nsis
a=qos-mech-recv: nsis
a=pcfg:1 t=2 a=1,2


One issue may be one of those famous middleboxes that may want to strip
away either rsvp or nsis along the path. In principle it should be OK
for a SDPCapNeg aware middlebox to modify the a=acap lines. An SDPCapNeg
unaware middle box is more troublesome.

That said, I really don't think that one need to use SDPCapNeg for this
purpose, if SDPMedCapNeg is also used there may in theory be use cases
where one wish to offer different resource reservation for different
codec(alternatives), it sounds a little odd though..

My 99 cents
/Ingemar

 


> -----Original Message-----
> From: Christer Holmberg 
> Sent: den 9 december 2008 18:45
> To: Ingemar Johansson S; '[e-mail]'
> Subject: RE: I-D Action:draft-ietf-mmusic-qos-identification-03.txt
> 
> 
> Hi, 
> 
> >I don't think that there is anything in the SDPCapNeg 
> framework that does this but it is fairly straight forward to 
> include the attribute into the SDPCapNeg framework if needed.
> 
> Sure, you can include the attribute, and of course we need to 
> define an attribute for this.
> 
> But, currently the attribute itself can be used to provide 
> different alternatives. Why can't capneg be used for that?
> 
> Regards,
> 
> Christer
> 
> 
> > Date: Mon, 8 Dec 2008 12:48:57 +0100
> > From: "Christer Holmberg" <[e-mail]>
> > Subject: Re: [MMUSIC] I-D
> > Action:draft-ietf-mmusic-qos-identification-03.txt
> > To: <[e-mail]>
> > Message-ID:
> > 	
> > <[e-mail]
> > csson.se>
> > 	
> > Content-Type: text/plain;	charset="us-ascii"
> > 
> > 
> > Hi,
> > 
> > Can't this be done using CapNeg?
> > 
> > Regards,
> > 
> > Christer
> > 
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of
> > [e-mail]
> > > Sent: 18. marraskuuta 2008 18:30
> > > To: [e-mail]
> > > Cc: [e-mail]
> > > Subject: [MMUSIC] I-D
> > > Action:draft-ietf-mmusic-qos-identification-03.txt
> > > 
> > > A New Internet-Draft is available from the on-line 
> Internet-Drafts 
> > > directories.
> > > This draft is a work item of the Multiparty Multimedia
> > Session Control
> > > Working Group of the IETF.
> > > 
> > > 
> > > 	Title           : Quality of Service (QoS) Mechanism 
> > > Selection in the Session Description Protocol (SDP)
> > > 	Author(s)       : J. Polk, et al.
> > > 	Filename        : draft-ietf-mmusic-qos-identification-03.txt
> > > 	Pages           : 10
> > > 	Date            : 2008-11-18
> > > 
> > > The offer/answer model for SDP assumes that endpoints establish 
> > > somehow the QoS required for the media streams they establish.
> > > Endpoints in closed environments typically agree out of 
> band (e.g., 
> > > using configuration information) which QoS mechanism to use.
> > > However, on the Internet, there is more than one QoS service 
> > > available.  Consequently, there is a need for a mechanism
> > to negotiate
> > > which QoS mechanism to use for a particular media stream.
> > > This document defines such a mechanism.
> > > 
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-qos-iden
> > > tification-03.txt
> > > 
> > > Internet-Drafts are also available by anonymous FTP at:
> > > ftp://ftp.ietf.org/internet-drafts/
> > > 
> > > Below is the data which will enable a MIME compliant mail reader 
> > > implementation to automatically retrieve the ASCII version of the 
> > > Internet-Draft.
> > > 
> > 
> > 
> > ------------------------------
> > 
> > Message: 2
> > Date: Mon, 08 Dec 2008 13:34:54 +0100
> > From: Christian Haas <[e-mail]>
> > Subject: Re: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc2326bis-19.txt
> > To: R?mi Denis-Courmont  <[e-mail]>
> > Cc: [e-mail]
> > Message-ID: <[e-mail]>
> > Content-Type: text/plain; charset=iso-8859-1; format=flowed
> > 
> > 
> > R?mi Denis-Courmont wrote:
> > > So POP3, IMAP, HTTP, and every other IETF TCP-based
> > protocol are impractical?
> > >
> > > When Web browsers want to avoid HoL blocking, they open multiple 
> > > connections in parallel. And if the system is too
> > constrained to keep
> > > state for concurrent TCP sessions, then why the heck would it be 
> > > capable of maintaining the exact same state one layer up 
> the stack?!
> > >   
> > Ok, I think either of us is getting the other one on the wrong foot 
> > here
> > - this went into some direction I was not aiming for. I want to go 
> > back a few steps and describe what it's about for me.
> > I am in no way contesting the problem of recreating the 
> sequence about 
> > transmission and reception of messages and I'm aware of the 
> features 
> > that a TCP connection has.
> > 
> > In my case I have one server with two resources A and B (which have 
> > nothing to do with each other) and one client that wants to access 
> > them
> > - also independently from each other. Yet for all it is 
> defined that 
> > one resource may have only one action active at a time (We agree 
> > here). I would furthermore expect the system to be capable that the 
> > client can access both resources
> > simultaneously: While the response to request A1 is pending for 
> > resource A, the request B1 can be sent regarding B, but a 
> request A2 
> > would have to wait until A1 is completed of course.
> > For simplicity I now only focus on transport via TCP to 
> have a strict 
> > ordering of message transmission and reception settled:
> > As you described, having the client open two dedicated TCP 
> connections 
> > (one regarding A, one regarding B) could be one solution (both 
> > resources are accessed simultaneously).
> > Yet the constrain I want to add is that the client can only use one 
> > TCP connection for all (control) communication. I do see the 
> > possibility to implement this pooling by using a combination of 
> > pipelining and the session identifier, but what I do not understand 
> > (and perhaps I got you wrong there) is why the B1 request 
> /also/ would 
> > have to wait until the response of A1 arrived - they still have 
> > nothing to do with each other.
> > 
> > The knot in my mind I'm having is why it is allowed to access two 
> > resources simultaneously (and independently) using two dedicated 
> > connections, but not via one connection...
> > 
> > If this were allowed, a response would need some sort of 
> > identification
> > (reference) by which the sender knows to what original 
> request it was 
> > sent (The response to B1 might be earlier than for A1). For 
> me it is 
> > not about recreating the order of transmissions, but matching the 
> > responses to the original requests - for now I would have used CSeq 
> > for this, since Session is not always present.
> > 
> > Regards,
> > ch
> > 
> > 
> > 
> > ------------------------------
> > 
> > Message: 3
> > Date: Mon, 8 Dec 2008 05:35:59 -0700
> > From: "Jean-Francois Mule" <[e-mail]>
> > Subject: [MMUSIC] Poll for interim meeting on RTSP/2.0, 2nd half of
> > 	January
> > To: <[e-mail]>
> > Message-ID:
> > 	
> > <[e-mail]>
> > Content-Type: text/plain;	charset="iso-8859-1"
> > 
> > All,
> > 
> >    As you may have heard, the idea of having interim 
> meetings in Malta 
> > is off the table.
> > 
> >    Given we know a few folks were interested in getting together 
> > before San Francisco to make progress on RTSP/2.0, Joerg 
> and I would 
> > like to poll the group to see who would be willing to attend a 
> > face-to-face meeting in January in Europe, somewhere like Helsinki, 
> > Stockholm or Paris.
> > 
> >    One proposal is to organize a one- or two-day interim meeting 
> > during the week of January 26 in Paris when the 3GPP
> > SA4 folks are meeting.  Some of these folks do care about 
> RTSP inside 
> > and outside 3GPP.  Another is to host the meeting in 
> Helsinki sometime 
> > around mid-January.  Last but not least is the idea of scheduling 
> > focused conference calls in the same timeframe to resolve specific 
> > issues.
> > 
> > Let us know.
> > Thanks,
> > Joerg and Jean-Fran?ois.
> > 
> > 
> > 
> > ------------------------------
> > 
> > Message: 4
> > Date: Mon, 8 Dec 2008 14:53:50 +0200
> > From: " R?mi Denis-Courmont" <[e-mail]>
> > Subject: Re: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc2326bis-19.txt
> > To: "ext Christian Haas" <[e-mail]>
> > Cc: [e-mail]
> > Message-ID: <[e-mail]>
> > Content-Type: text/plain;  charset="iso-8859-1"
> > 
> > On Monday 08 December 2008 14:34:54 ext Christian Haas, you wrote:
> > > Yet the constrain I want to add is that the client can 
> only use one 
> > > TCP connection for all (control) communication. I do see the 
> > > possibility to implement this pooling by using a combination of 
> > > pipelining and the session identifier, but what I do not 
> understand 
> > > (and perhaps I got you wrong there) is why the B1 request
> > /also/ would
> > > have to wait until the response of A1 arrived - they still
> > have nothing to do with each other.
> > 
> > You don't have to wait to send the B1 _request_. However, the
> > B1 _response_ will not come until the A1 request has been processed 
> > and the A1 _response_ sent and received:
> > 
> > These are valid:
> > C->S: A1 request
> > C->S: B1 request
> > S->C: A1 response
> > S->C: B1 response
> > 
> > C->S: A1 request
> > S->C: A1 response
> > C->S: B1 request
> > S->C: B1 response
> > 
> > This is NOT valid:
> > C->S: A1 request
> > C->S: B1 request
> > S->C: B1 response
> > S->C: A1 response
> > 
> > > The knot in my mind I'm having is why it is allowed to access two 
> > > resources simultaneously (and independently) using two dedicated 
> > > connections, but not via one connection...
> > 
> > Nobody said this was forbidden. The draft even recommends reusing 
> > connections for independent sessions (to spare server connections).
> > 
> > > If this were allowed, a response would need some sort of 
> > > identification
> > > (reference) by which the sender knows to what original
> > request it was
> > > sent (The response to B1 might be earlier than for A1). For
> > me it is
> > > not about recreating the order of transmissions, but matching the 
> > > responses to the original requests - for now I would have 
> used CSeq 
> > > for this, since Session is not always present.
> > 
> > The sender knows how to match responses to requests because 
> it knows 
> > in which order requests were sent, and it can assume that responses 
> > are in that same order.
> > 
> > --
> > R?mi Denis-Courmont
> > Maemo Software, Nokia Devices R&D
> > 
> > 
> > ------------------------------
> > 
> > Message: 5
> > Date: Mon, 08 Dec 2008 15:09:30 +0100
> > From: Magnus Westerlund <[e-mail]>
> > Subject: Re: [MMUSIC] Poll for interim meeting on RTSP/2.0,	2nd half
> > 	of January
> > To: Jean-Francois Mule <[e-mail]>
> > Cc: [e-mail]
> > Message-ID: <[e-mail]>
> > Content-Type: text/plain; charset=ISO-8859-1
> > 
> > Hi,
> > 
> > I will attend a face to face interim meeting as long as we have 
> > sufficient participation. Otherwise I think the will have 
> to do with a 
> > call.
> > 
> > After all the goal with the interim will be to discuss open issues 
> > that are raised in the review of the next version of the draft.
> > 
> > Cheers
> > 
> > Magnus
> > 
> > Jean-Francois Mule skrev:
> > > All,
> > > 
> > >    As you may have heard, the idea of having interim
> > meetings in Malta is off the table.
> > > 
> > >    Given we know a few folks were interested in getting
> > together before San Francisco to make progress on RTSP/2.0, 
> Joerg and 
> > I would like to poll the group to see who would be willing 
> to attend a 
> > face-to-face meeting in January in Europe, somewhere like Helsinki, 
> > Stockholm or Paris.
> > > 
> > >    One proposal is to organize a one- or two-day interim
> > meeting during the week of January 26 in Paris when the 3GPP
> > SA4 folks are meeting.  Some of these folks do care about 
> RTSP inside 
> > and outside 3GPP.  Another is to host the meeting in 
> Helsinki sometime 
> > around mid-January.  Last but not least is the idea of scheduling 
> > focused conference calls in the same timeframe to resolve specific 
> > issues.
> > > 
> > > Let us know.
> > > Thanks,
> > > Joerg and Jean-Fran?ois.
> > > 
> > > _______________________________________________
> > > mmusic mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/mmusic
> > > 
> > 
> > 
> > --
> > 
> > Magnus Westerlund
> > 
> > IETF Transport Area Director & TSVWG Chair
> > 
> ----------------------------------------------------------------------
> > Multimedia Technologies, Ericsson Research EAB/TVM
> > 
> ----------------------------------------------------------------------
> > Ericsson AB                | Phone  [phone]
> > F?r?gatan 6                | Mobile [phone]
> > SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> > 
> ----------------------------------------------------------------------
> > 
> > 
> > ------------------------------
> > 
> > Message: 6
> > Date: Mon, 8 Dec 2008 15:13:18 +0100
> > From: "Ingemar Johansson S" <[e-mail]>
> > Subject: Re: [MMUSIC] RFC 3890: b=TIAS value when multiple payloads
> > To: <[e-mail]>
> > Message-ID:
> > 	
> > <[e-mail]
> > csson.se>
> > 	
> > Content-Type: text/plain;	charset="US-ASCII"
> > 
> > Hi
> > 
> > My 99 cents is that you need to pick the worst case like you do in 
> > your example.
> > An alternative that is IMHO a lot more attractive is to use the SDP 
> > capability negotiation framework and its extensions (Media 
> > capabilities and Miscellaneous capabilities.
> > http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-sdp-capabili
> > ty-negotia
> > tion/
> > http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-sdp-media-ca
> > pabilities
> > /
> > 
> > That would allow you to specify AS, TIAS, maxprate, 
> ptime.... for each 
> > alternative.
> > 
> > Regards
> > /Ingemar
> >   
> > 
> > > Date: Fri, 5 Dec 2008 18:07:42 +0800
> > > From: "Vavilapalli Srikanth-A19563" <[e-mail]>
> > > Subject: [MMUSIC] RFC 3890: b=TIAS value when multiple payloads
> > > 	present in a	media line
> > > To: "mmusic (E-mail)" <[e-mail]>
> > > Message-ID:
> > > 	<[e-mail]>
> > > Content-Type: text/plain; charset="us-ascii"
> > > 
> > > Hi
> > >  
> > > If there are more than one audio codec present in m= line in SDP, 
> > > what should the following SDP attributes represent?
> > >  
> > > 1) b=AS: The maximum of (application specific bandwidth for any 
> > > codec in the m=line)?
> > > 2) b=TIAS: The maximum of (bitrates for any codec in the m=line)?
> > > 3) a=maxprate: The maximum of (packet rates for any codec in the 
> > > m=line)?
> > > 4) a=ptime: The minimum of (packetization time for any 
> codec in the 
> > > m=line)?
> > >  
> > > Please let me know if my understanding is correct or not.
> > >  
> > > For example if UAC wishes to offer two codecs G711A with 
> > > packetization of 20ms and bitrate of 64000bps and G728 with 
> > > packetization of 10ms and bitrate of 16000bps, then is 
> the following 
> > > SDP correct?
> > >  
> > > m=audio 50000 RTP/AVP 8 98
> > > a=rtpmap:98 G728/8000
> > > b=AS:96    (considering 40 Bytes of overhead per packet)
> > > b=TIAS:64000
> > > a=maxprate:100
> > > a=ptime:10
> > >  
> > >  
> > > Regards
> > > Srikanth
> > > -------------- next part -------------- An HTML attachment was 
> > > scrubbed...
> > > URL: 
> > > <http://www.ietf.org/pipermail/mmusic/attachments/20081205/99d
> > > 9865d/attachment-0001.htm>
> > > 
> > > ------------------------------
> > 
> > 
> > ------------------------------
> > 
> > Message: 7
> > Date: Mon, 08 Dec 2008 15:49:44 +0100
> > From: Magnus Westerlund <[e-mail]>
> > Subject: Re: [MMUSIC] I-D Action:draft-ietf-mmusic-rfc2326bis-19.txt
> > To: R?mi Denis-Courmont <[e-mail]>
> > Cc: [e-mail]
> > Message-ID: <[e-mail]>
> > Content-Type: text/plain; charset=ISO-8859-1
> > 
> > R?mi Denis-Courmont skrev:
> > 
> > >> Please do remember that TCP is not guaranteed free from errors.
> > > 
> > > I don't understand this argument at all. If a TCP session
> > suffers packet loss
> > > (whether it's recovered or not) or re-ordering, the
> > applications layer will
> > > NOT see it, so CSeq does not help in any meaningful way. 
> > HTTP does not have
> > > CSeq, yet we have no problem debugging it.
> > 
> > No, I mean bit-errors, character blanking or other TCP payload 
> > modification errors creeping through the Internet checksum. 
> That can 
> > corrupt message boundaries and result in that the server 
> responds two 
> > requests as one or make the client interpret a single 
> message as being 
> > shorter and that there are additional ones. After such an error has 
> > been introduced into your connection it takes some care to 
> recover. I 
> > would claim that cseq has some benefits in that.
> > 
> > > 
> > > As for packet captures, we have the TCP sequence number
> > already. Wireshark has
> > > long since learnt how to re-assemble TCP.
> > > 
> > 
> > That wasn't the issue. If you do one sided or in the middle logging 
> > and save the messages as they are sent and later responses received 
> > the request and response will not be nicely ordered in the log file.
> > Thus you need to parse larger structures to determine what response 
> > belongs to which request. Not that it is impossible without 
> it is only 
> > simpler.
> > 
> > Cheers
> > 
> > Magnus Westerlund
> > 
> > IETF Transport Area Director & TSVWG Chair
> > 
> ----------------------------------------------------------------------
> > Multimedia Technologies, Ericsson Research EAB/TVM
> > 
> ----------------------------------------------------------------------
> > Ericsson AB                | Phone  [phone]
> > F?r?gatan 6                | Mobile [phone]
> > SE-164 80 Stockholm, Sweden| mailto: [e-mail]
> > 
> ----------------------------------------------------------------------
> > 
> > 
> > ------------------------------
> > 
> > _______________________________________________
> > mmusic mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/mmusic
> > 
> > 
> > End of mmusic Digest, Vol 56, Issue 12
> > **************************************
> > 
> 
_______________________________________________
mmusic mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mmusic