[sip-overload] AD review: draft-ietf-soc-overload-design-04

[Robert Sparks <[e-mail]>]

There are a few things to address before moving this document into IETF LC.

1) "This document is a product of the SIP overload control design team." should be
adjusted to reflect its genesis in the design team and production in the working
group.

2) The document has several passages that are telephony centric - speaking of 
failed calls, call attempts, and having the mechanism reject calls. This language
should be generalized - the intended mechanism applies to all uses of SIP.

3) I don't think the distinction the last paragraph of 5.2 tries to draw is
constructed correctly. The TCP packets between two routers are analogous to the individual
SIP messages between the SIP servers you describe - the routers will see many
TCP packets with different source and destination addresses. The whole point is that
congenstion is managed by the behavior of the endpoints in a given stream. A direct
comparison would be against mechanisms that only affected the behaviors of a 
particular pair of SIP endpoints - not changing the behavior of the SIP servers at all.
Please adjust or remove this paragraph.

4) The end of section 6 talks about asking UAs to wait using 503/retry-after. What
503/retry-after does is ask the next upstream element to wait. I think it's the intention
to scope this discussion to the case where the UA _is_ the next upstream element, but that
needs to be made even more clear. The section should also discuss how an element knows
that the next upstream element is a UA and not another proxy.

5) It would help to clarify in Section 9.1 (particularly paragraph 2) that "next request"
is "the start of another transaction", and not "retransmissions in any ongoing transaction".

6) In section 9.3, I disagree that 100 Trying does not provide confirmation of receipt
of a message. That is _exactly_ what 100 Trying does, and its point is to affect the
transaction state machine's reliability mechanisms. It means it has been accepted for
processing  - this hop is taking responsibility for it now.  If you have an implementation 
that would cause transaction reliability to fail by sending a 100 early in the processing
as you suggest, that implementation in not conformant to the specification. Are you
instead trying to say that the 100 Trying does not indicate that the message has 
already been forwarded?

7) Did you mean dialog instead of session in the first paragraph of section 12? Surely we
have actual research backing up the claim "As a general rule". Can we point to that please?

8) The security consideration section should note what key security properties
each of the possible models have and what influence that could have on the mechanism
chosen, particularly when specific mechanics have been discussed in a model's section.
For instance, the mechanism detailed in the 4th paragraph of 9.1 is exposed if an attacker
can easily make a new server appear to appear (by sending one message perhaps), cutting
traffic at legitimate servers down by 1/n with each new malicious appearance.

Nits:

Section 2 Paragraph 1 Sentence 1: s/to the SIP congestion collapse/to SIP congestion collapse/

Section 2 Paragraph 3: 
- s/spend/spent/g. Suggest changing this sentence to "Discarding a SIP 
  message after spending the resources to parse it is expensive." 
- s/less and less/fewer/,  s/more and more/more/
- s/slope/rate/

Section 6 Paragraph 5: s/determine much traffic/determine how much traffic/