Subject: [sip-overload] Fwd: Re: [dispatch] Chartering SIP Overload

From: "James M. Polk" <[email-masked]>
Date: Mon, 18 Jan 2010 13:23:41 -0600

It appears that multiple threads on different lists are talking about 
the same subject. I just sent this to another list, that this list 
ought to see IMO

James

>Date: Mon, 18 Jan 2010 13:21:01 -0600
>To: "Bernard Aboba" <[email-masked]>, <[email-masked]>
>From: "James M. Polk" <[email-masked]>
>Subject: Re: [dispatch] Chartering SIP Overload
>Cc: Lars Eggert <[email-masked]>, Magnus Westerlund 
><[email-masked]>
>
>At 01:08 PM 1/18/2010, Bernard Aboba wrote:
>>Content-Type: multipart/alternative;
>>         boundary="----=_NextPart_000_0676_01CA982E.930534F0"
>>Content-Language: en-us
>>
>>Henning said:
>>
>>"In addition, if multiple, independent simulations, published in 
>>peer-reviewed conferences, are no longer sufficient for 
>>standards-track designation, I'm at a bit of a loss to figure out 
>>what more any algorithm-containing protocol spec should do to avoid 
>>the "experimental" label. We constantly complain that we can't move 
>>specs up the maturity ladder; now, we can't even get *on* the ladder..."
>>
>>[BA] Experimental RFCs can subsequently be placed on the standards 
>>track, based on implementation evidence.  This is routinely done in 
>>the Transport Area, for example.
>>
>>IMHO, the major difference between "Experimental" and "Proposed" in 
>>this particular case would be whether the algorithm is considered 
>>safe for mass deployment on the Internet.   If we have enough 
>>information from existing implementations to know that there is no 
>>potential for congestive collapse or other catastrophic failures, 
>>then the document should be allowed to be published as a Proposed 
>>Standard.  Rather than writing this into the charter, the WG and 
>>IESG could be allowed to make the determination based on the 
>>evidence presented within the WG.  The process for making this 
>>judgment is relatively well established (at least within the Transport Area).
>
>Bernard
>
>Transport is focus on congestion, sure, but it is focused on 
>congestion when a protocol can't do anything about the congestion 
>(i.e., something has to be done because the protocol can't react 
>appropriately on its own to address or solve congestion -- for 
>something like HTTP or FTP, not about TCP vs UDP).
>
>Overload effort is what can be done in SIP to help alleviate the TCP 
>vs UDP issues at a SIP entity.  I'd argue that isn't so much about 
>TCP or SCTP or DCCP or UDP -- would you?
>
>As far as the protocol is concerned, a SIP server (whether it is 
>experiencing congestion or not) is a destination entity, not a 
>transit entity like a classic router. That makes this scenario wrt 
>Overload special, if not unique compared to other transport protocols.
>
>I don't believe it ought to be treated or thought of in the same 
>light as other transport solutions to congestion.
>
>>_______________________________________________
>>dispatch mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/dispatch