Hi Rohan, To start with I have to apologize that I have not been able to attend the latest IETF meetings (and will not be able to make it for the next meeting either). That said I try to be reasonable in my posts to the mailing lists even if I am not totally happy to the fact that these issues were raised already in March but will not be addressed before the end of June. Last year Outbound was considered urgent and many WG members wanted it to be finished as soon as possible, but recently the push to get it out seems to have vanished somewhere. Maybe there has been something more urgent gaining the focus.
Responding to the comments you made: >At IETF68 we agreed to add an indicator "timed-keepalive" that the >*server* expects keepalives to happen according to the timers >recommended in the draft. If the server asks for this, then the >client needs to send pings (STUN over UDP or double CRLF over TCP or >TLS). I was able to find a note in the IETF68 SIP meeting minutes for this, however I am not able to grasp the value of this indicator (unless it is supposed to carry a value for the timers, but how could the server know the keepalive times of the NATs between the UA and proxy ?) >The *client* can tell if the server will send pongs (STUN >binding responses over UDP, or single CRLF over TCP or TLS) if the >server advertises "keep-stun" or "keep-crlf". This allows a battery >operated client to use TCP keepalives or send pings less often if the >server allows, and it allows the client in general to know if they >should expect to receive pongs. What I am worried about all this is that it seems to make the machinery quite complex. My preference would be to keep things simple as creeping complexity seems to be a common problem for SIP and its extensions. (E.g. I have heard many concerns that the specs from the SIMPLE WG are really far from simple :-) Yes I was one of the proponents for the UA probing STUN support of proxy before starting to send STUN requests to the SIP port of the proxy. However one solution for that, OPTIONS probing for STUN support, was ultimately deemed too complex in IETF68 and was agreed to be removed from the draft according to the minutes. To me it seems that introduction of various flags like "timed-keepalive", "keep-stun" and "keep-crlf" will in the end have similar effect to the complexity, which is not probably justified by the value gained. I even fail to see how those flags would really help any battery operated mobile device. The only thing which really helps is the possibility for the UA to use TCP instead of UDP as TCP has longer keepalive timers. After this email from Cullen in the end of March... http://www1.ietf.org/mail-archive/web/sip/current/msg18514.html ... I was expecting to see a bit different solution in the next version of the Outbound draft as suggested by me and Christer (to what Cullen agreed): 1. UA would check the transports supported by the proxy via DNS (NAPTR and/or SRV) 2. The proxy would indicate its Outbound support e.g. by adding 'ob' parameter to its URI within the Path header 3. When UA knows the supported transports (from DNS) and Outbound support (from Path header) it can be sure that the proxy supports all keepalive methods Outbound has specified for those transports. At this point the UA can choose its keepalive method amongst: a) UDP: UA MUST use STUN b) TCP: UA can use either CRLF or TCP keepalives 4. Whatever keepalive method (type of pings) is selected by the UA, the proxy will send corresponding responses (pongs): a) UDP: STUN responses b) TCP: CRLF pongs or TCP ACKs 5. When sending the keepalives the UA would use timers as specified in the normative text of SIP Outbound draft. Defined like that all the other flags "timed-keepalive", "keep-stun" and "keep-crlf" could be removed from the draft. I do not see enough value for those flags which seem to a) enable the proxy to support just one keepalive method for TCP; and b) somehow complex negotiation between UA and proxy whether regular keepalive or heartbeat messages are expected. Any comments to this proposal ? If you find it acceptable, could you please incorporate it either within the next version of the Outbound draft or raise it as an open question for the meeting to decide ? P.S. Earlier I gave a comment like this for CRLF "pongs": >> How does the addition of CRLF keepalive without CRLF "pong" >> make the situation worse compared using TCP keepalive, which >> has been considered acceptable for Outbound over several >> successive draft revisions and is still there without any >> "pong" other than TCP ACK ? One of my colleagues pointed out that the OS implementations for TCP keepalive typically have some timer for receiving the ACKs. Thus it would mean TCP keepalive has an implicit timeout behaviour which CRLF keepalives lack. After this comment I can accept the value of CRLF "pong" and do not have any problem with it. Thanks, Erkki >On 3/8/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: >> Hi, >> >> >> Question 1: >> >> >> >> Is the single CRLF "pong" necessary or could the UA detect the >> >> flow failure just by receiving a socket or ICMP error when the >> >> connection is broken and not able to pass the double-CRLF "ping" >> >> to the proxy ? >> > >> >Sure, if you don't mind not getting calls for 10 minutes. >And if some >> >moron hasn't blocked ICMP on your network (which unfortunately >> >corpsec guidelines frequently recommend). >> >> To overcome this problem, doesn't Outbound strongly promote the >> UA registering over multiple flows ? >> >> This requires the UA to detect when a flow fails. Since >> such detection takes time and leaves a window of opportunity for >> missed incoming requests, this mechanism allows the UA to use >> multiple flows to the proxy or registrar. >> >> Are you suggesting that this mechanism in the Outbound only >> has limited or even no value ? >> >> >It can take TCP a LONG time to know a flow has failed. This is a >> >large part of why I liked the STUN model. >> >> How does the addition of CRLF keepalive without CRLF "pong" >> make the situation worse compared using TCP keepalive, which >> has been considered acceptable for Outbound over several >> successive draft revisions and is still there without any >> "pong" other than TCP ACK ? >> >> And as you say, it can take TCP a LONG time to know a flow >has failed, >> but not necessarily. The device which rebooted might indicate the >> broken connection by sending TCP RST, which immediately tells the >> sender about the flow failure. >> >> Even the STUN over TCP model will not guarantee an immediate >> detection of a failed flow as Outbound suggests that the time >> between successive keepalives over TCP should be between 95 and >> 120 seconds on top of which the STUN transaction adds 8 seconds >> to wait for the response. So even with STUN or CRLF "ping-pong" >> you could not getting calls for two minutes if the UA is relying >> on one single flow only or using two flows towards two different >> proxies over a single NAT which reboots. >> >> >> I am still questioning whether the requirement to add CRLF "pong" >> and 'keep-crlf' URI tags are really worth the extra complexity. >> Personally I am not at all convinced about it. >> >> Regards, >> >> Erkki >> >> _______________________________________________ >> Sip mailing list https://www1.ietf.org/mailman/listinfo/sip >> This list is for NEW development of the core SIP Protocol >> Use [EMAIL PROTECTED] for questions on current sip >> Use [EMAIL PROTECTED] for new developments on the application of sip >> > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
