Subject: Re: [dispatch] [httpstreaming] Q-HTTP

From: "Luby, Michael" <[email-masked]>
Date: Tue, 9 Nov 2010 18:15:46 -0800

+1
This is the whole point of the 3GPP/MPEG/OIPF standards, i.e., accept HTTP
1.1 as a given and adapt to best effort networks without trying to "boil the
ocean" in terms of trying to change massively deployed server
infrastructure.
Mike

> Message: 3
> Date: Tue, 09 Nov 2010 17:22:44 -0600
> From: Henry Sinnreich <[email-masked]>
> Subject: Re: [dispatch] [httpstreaming]    Q-HTTP
> To: David Singer <[email-masked]>, "GARCIA ARANDA, JOSE JAVIER (JOSE
>         JAVIER)"        <[email-masked]>
> Cc: Ingemar Johansson S <[email-masked]>,
>         httpstreaming <[email-masked]>, [email-masked],
>         [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain;       charset="US-ASCII"
> 
> +1
> Fully agree.
> 
> Thanks, Henry
> 
> 
> On 11/9/10 4:31 AM, "David Singer" <[email-masked]> wrote:
> 
>> There is a bitter lesson I have learned over the years to do with QoS
>> reservation.
>> 
>> It is that there are two ways to solve a real-time bandwidth need.  One is to
>> reserve bandwidth, manage QoS and so on;  one gets protocols and systems like
>> diffserv, ATM, and so on.  The other is simply to have 'too much' of the
>> resource.  Though it feels wrong, the latter often ends up being the cheaper
>> and easier solution.  So, for example, voice over IP is getting used quite a
>> lot, and to good effect, on the internet today not because we have
>> successfully deployed any bandwidth reservation or QoS management protocols
>> and systems, but because the available bandwidth is, for the most part,
>> greatly in excess of what is needed, and the systems can adapt in real-time
>> to
>> what they get (rather than asking for what they want).  The same is true for
>> multimedia delivery;  the complexity of RTP + TCP friendliness + QoS
>> management is not worth it compared to having adaptable end-systems and
>> overall more bandwidth than needed.
>> 
>> (I worked on real-time scheduling systems as well, and the same applies;
>> it's
>> cheaper to have a processor which is much faster than needed, with a normal
>> scheduler, than to have a just-enough processor with a real-time scheduler).
>> 
>> I know, it 'feels' wrong.
>> 
>> David Singer
>> Multimedia and Software Standards, Apple Inc.
>> 
>> _______________________________________________
>> httpstreaming mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/httpstreaming
> 
> 
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Tue, 9 Nov 2010 19:46:01 -0500
> From: "Patel, Milan" <[email-masked]>
> Subject: [dispatch] FW: New Version Notification for
>         draft-patel-ecrit-sos-parameter-11
> To: <[email-masked]>,        <[email-masked]>
> Cc: [email-masked]
> Message-ID:
>         <[email-masked]>
> Content-Type: text/plain;       charset="utf-8"
> 
> Hi,
> 
> The latest version of draft-patel-ecrit-sos-parameter is now available. The
> draft describes a mechanism to requests pertaining to emergency registration,
> which is a requirement in 3GPP IMS based emergency services since release 7.
> The mechanism allows a registrar to identify emergency registration requests
> and act accordingly to perform the necessary admission control to remove
> subscription related restrictions that might otherwise prevent successful
> initiation of an emergency call.
> 
> In order to further progress this draft, please can you review the draft and
> provide any feedback to Robert and myself. Based upon your feedback, Robert
> will decide whether or not to AD sponsor the draft.
> 
> Best regards,
> Milan
> 
> -----Original Message-----
> From: IETF I-D Submission Tool [mailto:[email-masked]]
> Sent: Tuesday, November 09, 2010 11:34 AM
> To: Patel, Milan
> Subject: New Version Notification for draft-patel-ecrit-sos-parameter-11
> 
> 
> A new version of I-D, draft-patel-ecrit-sos-parameter-11.txt has been
> successfully submitted by Milan Patel and posted to the IETF repository.
> 
> Filename:        draft-patel-ecrit-sos-parameter
> Revision:        11
> Title:           SOS Uniform Resource Identifier (URI) Parameter for Marking
> of Session Initiation Protocol (SIP) Requests related to Emergency Services
> Creation_date:   2010-11-09
> WG ID:           Independent Submission
> Number_of_pages: 8
> 
> Abstract:
> This document defines a new Session Initiation Protocol (SIP) Uniform
> Resource Identifier (URI) parameter intended for marking SIP
> registration requests related to emergency calls and allow admission
> control to ensure successful initiation of emergency calls.  The
> usage of this new URI parameter complements the usage of the Service
> Uniform Resource Name (URN) and is not intended to replace it.
> 
> 
> 
> The IETF Secretariat.
> 
> 
> 
> 
> 
> 
> Milan Patel
> Consultant
> InterDigital Communications, LLC
> 
> 
> Tel.: +44 7917 678 250
> Fax:
> Email: [email-masked]
> http://www.InterDigital.com
> 
> 
> This e-mail is intended only for the use of the individual or entity to which
> it is addressed, and may contain information that is privileged, confidential
> and/or otherwise protected from disclosure to anyone other than its intended
> recipient. Unintended transmission shall not constitute waiver of any
> privilege or confidentiality obligation. If you received this communication in
> error, please do not review, copy or distribute it, notify me immediately by
> email, and delete the original message and any attachments. Unless expressly
> stated in this e-mail, nothing in this message or any attachment should be
> construed as a digital or electronic signature.
> 
> 
> ------------------------------
> 
> Message: 5
> Date: Wed, 10 Nov 2010 09:49:05 +0800
> From: Paul Kyzivat <[email-masked]>
> Subject: Re: [dispatch] FW: New Version Notification    for
>         draft-patel-ecrit-sos-parameter-11
> To: [email-masked]
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> I have a few questions about this:
> 
> - Is this intended to change the normative behavior of registrars as
> defined in 3261? (In most respects it might not - it may only be
> affecting behavior over and above normative behavior, such as
> authorization policy.)
> 
> - Is it intended that two contacts that differ only by the presence of
> the sos parameter may be concurrently registered? (I gather that is the
> intent, but am not certain.)
> 
> - Is it intended that the presence of the sos parameter in a contact
> enable the registration of that contact even in cases when the To-URI of
> the REGISTER request is not valid for the domain of the registrar?
> 
> Elaboration on the above:
> 
> 3261 section 10.3 calls out the rules the registrar must follow. Its
> much better if you are not suggesting changes to those. If you are, then
> you really need to spell out in black and white what specific changes
> you want in those rules.
> 
> Note that the ordering of the steps in that section calls for
> determining if the domain and AOR are valid before considering any of
> the contacts. If you expect the presence of ;sos in one of the contacts
> to alter that it will make things much more complex.
> 
> Those rules also call for comparison of URIs in the REGISTER request
> with those previously registered using SIP URI comparison rules. The
> comparison rules will result in two URIs comparing equal if they differ
> only by the presence of the sos parameter.
> 
>         Thanks,
>         Paul
> 
> On 11/10/2010 8:46 AM, Patel, Milan wrote:
>> Hi,
>> 
>> The latest version of draft-patel-ecrit-sos-parameter is now available. The
>> draft describes a mechanism to requests pertaining to emergency registration,
>> which is a requirement in 3GPP IMS based emergency services since release 7.
>> The mechanism allows a registrar to identify emergency registration requests
>> and act accordingly to perform the necessary admission control to remove
>> subscription related restrictions that might otherwise prevent successful
>> initiation of an emergency call.
>> 
>> In order to further progress this draft, please can you review the draft and
>> provide any feedback to Robert and myself. Based upon your feedback, Robert
>> will decide whether or not to AD sponsor the draft.
>> 
>> Best regards,
>> Milan
>> 
>> -----Original Message-----
>> From: IETF I-D Submission Tool [mailto:[email-masked]]
>> Sent: Tuesday, November 09, 2010 11:34 AM
>> To: Patel, Milan
>> Subject: New Version Notification for draft-patel-ecrit-sos-parameter-11
>> 
>> 
>> A new version of I-D, draft-patel-ecrit-sos-parameter-11.txt has been
>> successfully submitted by Milan Patel and posted to the IETF repository.
>> 
>> Filename:      draft-patel-ecrit-sos-parameter
>> Revision:      11
>> Title:                 SOS Uniform Resource Identifier (URI) Parameter for
>> Marking of Session Initiation Protocol (SIP) Requests related to Emergency
>> Services
>> Creation_date:         2010-11-09
>> WG ID:                 Independent Submission
>> Number_of_pages: 8
>> 
>> Abstract:
>> This document defines a new Session Initiation Protocol (SIP) Uniform
>> Resource Identifier (URI) parameter intended for marking SIP
>> registration requests related to emergency calls and allow admission
>> control to ensure successful initiation of emergency calls.  The
>> usage of this new URI parameter complements the usage of the Service
>> Uniform Resource Name (URN) and is not intended to replace it.
>> 
>> 
>> 
>> The IETF Secretariat.
>> 
>> 
>> 
>> 
>> 
>> 
>> Milan Patel
>> Consultant
>> InterDigital Communications, LLC
>> 
>> 
>> Tel.: +44 7917 678 250
>> Fax:
>> Email: [email-masked]
>> http://www.InterDigital.com
>> 
>> 
>> This e-mail is intended only for the use of the individual or entity to which
>> it is addressed, and may contain information that is privileged, confidential
>> and/or otherwise protected from disclosure to anyone other than its intended
>> recipient. Unintended transmission shall not constitute waiver of any
>> privilege or confidentiality obligation. If you received this communication
>> in error, please do not review, copy or distribute it, notify me immediately
>> by email, and delete the original message and any attachments. Unless
>> expressly stated in this e-mail, nothing in this message or any attachment
>> should be construed as a digital or electronic signature.
>> _______________________________________________
>> dispatch mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dispatch
>> 
> 
> 
> ------------------------------
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
> 
> 
> End of dispatch Digest, Vol 20, Issue 16
> ****************************************