Re: Last Call: draft-ietf-sipping-overload-reqs (Requirements for Management of Overload in the Session Initiation Protocol) to Informational RFC
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Last Call: draft-ietf-sipping-overload-reqs (Requirements for Management of Overload in the Session Initiation Protocol) to Informational RFC



I've updated the document with your suggested wording change in REQ 15.

Thanks,
Jonathan R.

Matt Mathis wrote:
> Your rewording looks good.  One minor suggestion for REQ 15:
> 
> <t hangText="REQ 15:"> In cases where a network element fails, is so 
> overloaded that it cannot process messages, or cannot communicate due to 
> a network failure or network partition, it will not be able to provide 
> explicit indications of the nature of the failure or its levels of 
> congestion. The mechanism must properly function in these cases. </t>
> 
>>> I would like to point out that TCP, IP and several other transport 
>>> protocols have evolved in the same direction as I am advocating for 
>>> SIP: the only robust indication that an error has occurred is 
>>> connection failure. 
>>
>> True, and we absolutely need to utilize that. However, I do not 
>> believe this eliminates the utility of explicit congestion indicators, 
>> as ECN provides (for example), as a way to further improve performance.
> 
> Normally ECN only reduces latency.  My usual metric for performance is 
> throughput, which is not generally improved by ECN.  But point taken.   
> And it
> doesn't effect the document.
> 
> 
> Thanks,
> --MM--
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
jdrosen at cisco.com
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
IETF mailing list
IETF at ietf.org
https://www.ietf.org/mailman/listinfo/ietf



Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.

Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.