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

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

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.

/Ingemar

> 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