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

From: Robert Sparks <[email-masked]>
Date: Fri, 4 Mar 2011 15:30:56 -0600

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/

---

From: Volker Hilt <[email-masked]>
Date: Thu, 10 Mar 2011 21:32:44 -0500

Robert,

thanks for the detailed review. More inline.

> adjusted to reflect its genesis in the design team and production in the working
Done.

> should be generalized - the intended mechanism applies to all uses of SIP.
Done.

> TCP packets with different source and destination addresses.The whole point is that
I've clarified this paragraph. The new version is below:

       Overload control for SIP servers is different from end-to-end
       congestion control used by transport protocols such as TCP. The
       traffic exchanged between SIP servers consists of many
       individual SIP messages. Each SIP message is typically created
       individually by a SIP UA (e.g., to start setting up a call) and
       each message has its own source and destination address. Even
       SIP messages containing identical SIP URIs (e.g., a SUBSCRIBE
       and a INVITE message to the same SIP URI) can be routed to
       different destinations. This is different from TCP which
       controls a large flow of packets (e.g., to transmit a file)
       between a single source and a single destination. If congestion
       occurs in a router, the sources can detect this condition and
       adjust the rate at which new packets are transmitted.

> that the next upstream element is a UA and not another proxy.
For this case, it is not important that the upstream neighbor is a UA or 
a proxy. The key is that there are many upstream neighbors that each 
contribute only a few requests. Edge proxy to UA is probably the common 
scenario for this case. I've clarified the text.

> is "the start of another transaction", and not "retransmissions in any ongoing transaction".
Done.

> instead trying to say that the 100 Trying does not indicate that the message has
This is based on a discussion in the design team. It was pointed out 
that it is common practice in SIP implementations to create 100 Trying 
very early in the processing and that a message can still be dropped 
(e.g., from an overflowing buffer).

Maybe someone who had the original comment can comment on this. I'd be 
happy to make the change as needed.

> 7) Did you mean dialog instead of session in the first paragraph of section 12?

Yes.

> Surely we
The motivation for this recommendation is driven by user experience. 
Dropping mid-dialog requests will create a situation in which a user 
was, e.g., able to set up a call but is unable to modify it after that 
or terminate it. Targeting requests that initiate a dialog will, e.g., 
lead to calls that cannot be set up, which is more familiar to a user.

> traffic at legitimate servers down by 1/n with each new malicious appearance.
I will address this comment in the next version of the draft.

> Section 6 Paragraph 5: s/determine much traffic/determine how much traffic/
Done.

Thanks!

Volker

>
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload