Subject: Re: [dispatch] Chartering SIP Overload

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 18 Jan 2010 11:08:33 -0800

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).

---

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

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:
>
>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

---

From: Lars Eggert <[email-masked]>
Date: Mon, 18 Jan 2010 21:46:22 +0200

Hi,

after reading Bernard's email below, I believe we're making the same argument using different words.

Some comments below.

>> specs up the maturity ladder; now, we can't even get *on* the ladder..."

It's never been the case that research work, even a very substantial effort with multiple simulations and several solid academic publications such as the SIP overload work, is somehow preordained for standards track publication.

>> Standard.

Exactly.

>>  Rather than writing this into the charter, the WG and 

I could agree to this approach. 

(I'm guessing below is what James wrote?)

> TCP or SCTP or DCCP or UDP -- would you?

I don't follow. Congestion control is about building a control loop for a flow, and doing it in a way such that the entire system (= many congestion controlled flows) is stable.

The SIP overload work is doing something very similar, except that it's trying to control the volume of SIP messages being exchanged between servers.

> Overload special, if not unique compared to other transport protocols.

No, the fact that it's an endpoint at the SIP layer makes this EXACTLY like the transport congestion control problem. (Just one level up in the stack.)

> light as other transport solutions to congestion.

I want to make clear that I wasn't the person who started drawing analogies to transport protocols. There are obvious similarities, because both mechanisms build control loops, but that is not a reason to blindly adopt some standardization "rules" here that we are doing over in TSV for congestion control, and that's not at all why I raised the issue I raised.

(I realize that I spent the last few paragraphs talking about congestion control, but that's because I'm disagreeing what what you wrote about congestion control, and not because I think we should simply apply the "rules" we use for congestion control standardization to SIP overload.)

In Bernard's words, the issue is that I'm unconvinced that we've seen sufficient evidence at this time to decide whether the SIP overload mechanism is safe for mass deployment. 

Lars