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

[Volker Hilt <[e-mail]>]

Robert,

thanks for the detailed review. More inline.

On 3/4/2011 4:30 PM, Robert Sparks wrote:
> 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.
>
Done.

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

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

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

> 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".
>
Done.

> 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?
>
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
> have actual research backing up the claim "As a general rule". Can we point to that please?
>
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.

> 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.
>
I will address this comment in the next version of the draft.

> 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/
>
Done.

Thanks!

Volker

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