Subject: RE: [Speermint] comments on draftdraft-creighton-khandpur-speermint-srv-naptr-use-01

From: "Michael Hammer \(mhammer\)" <[email-masked]>
Date: Mon, 2 Oct 2006 10:34:14 -0400

I did not understand your RFC3261 comment.  It says you should try an
alternate server and not retry the server sending the 503 until after
the retry time.

Mike

> -----Original Message-----
> From: Klaus Darilion [mailto:[email-masked]] 
> Sent: Friday, September 29, 2006 6:24 AM
> To: [email-masked]
> Subject: [Speermint] comments on 
> draftdraft-creighton-khandpur-speermint-srv-naptr-use-01
> 
> Hi Tom, Gaurav!
> 
> Following some comments.
> 
> 
> > 3. Session Peering Setup
> >  
> >    SIP systems are represented by user agents (UA).  In the diagram 
> >    below, a user agent (UA1), hosted by a service provider SP1, 
> >    initiates a call to a User Agent (UA2), hosted by 
> service provider 
> >    SP2.  The egress SIP server of SP1 is a SIP stateful Session 
> > Peering
> 
>                                                   ^^^^^^^^^ 
> IMO we should not require the PeeringProxy to be stateful (btw: 
> transaction stateful or dialog stateful).
> 
> 
> >    The figure below shows a high level SIP call flow 
> setting up a SIP 
> >    peering session between SP1 and SP2. All SIP signaling MUST go 
> >    through the SPP1 and SPP2 as these are the ingress and 
> egress points 
> >    in SP1 and SP2 network. 
> >     
> >                  UA 1  SPP 1  DNS 1  DNS 2  SPP 2   UA 2 
> >                   |      |      |      |      |      | 
> >                   |INVITE|      |      |      |      | 
> >                   |----->|      |      |      |      | 
> >                   |     NAPTR Query    |      |      | 
> >                   |      |----->|      |      |      | 
> >                   |    NAPTR Response  |      |      | 
> >                   |      |<-----|      |      |      | 
> >                   |     SRV Query      |      |      | 
> >                   |      |----->|      |      |      | 
> >                   |   SRV+A Response   |      |      | 
> >                   |      |<-----|      |      |      | 
> 
> I wonder why you combine SRV+A in one response. This depends 
> on the DNS server. If you have a "simple" resolver, you have 
> to ask for each record separate. If you have an "intelligent" 
> resolver, you will get 
> NAPTR+SRV+A in the same response (if SRV+A are cached or responded by
> the authoritative server).
> 
> Further it depends if SPP1 does cache DNS too. The SIP proxies I know 
> will do 3 lookups (regardless if the additional section 
> contains SRV and 
> A or not) as they do not have a DNS cache.
> 
> Thus, I suggest to either draw 3 lookups in the figure 1. 
> NAPTR, 2. SRV, 
> 3. A/AAAA or to draw only one lookup.
> 
> 
> > 3.1 TARGET Determination 
> >  
> >    The target resource is identified with a SIP or SIPS 
> URI.  This is 
> >    the URI in the Route header, if present, or the URI from 
> the request 
> >    URI of the SIP INVITE received by SPP1.  
> 
> I would write "topmost Route header" just for clarification.
> 
> > 3.2 NAPTR Lookup 
> 
> I would add somewhere that NAPTR/SRV/A lookups must be 
> skipped according 
> to RFC 3263 [3] if transport/port/IP are already specified in 
> the target 
> URI.
> 
> >    DNS MUST return at least three records - one with "SIP+D2T", one 
> >    with "SIP+D2U" and one with "SIPS+D2T" service type for 
> the case of 
> >    direct peering (section 4.3 in [6]). "SIPS+D2T" is not a 
> MUST for 
> >    indirect (transit) peering (section 4.4 in [6]) since 
> domain validation 
> >    as specified in section 26.3.2.2 of [1] for TLS at layer 
> 5 will not work 
> >    for indirect peering.
> 
> This sounds like TLS can't be used in transit peering. I 
> would like to 
> use TLS also in transit scenarios. IMO it would be better to remove 
> layer 5 certificate validation (section 26.3.2.2 of [1] ) 
> than removing 
> TLS completely.
> 
> > 3.3 SRV Lookup 
> >     
> ...
> >    Alternatively, if no NAPTR records are found, then SPP1 uses the 
> >    preferred transport protocol and issues an SRV query for that 
> >    specific transport using sips for SIPS URI and SIP URI 
> with TLS and 
> >    sip for SIP URI. 
> 
> IMO this sentence is not clear. What do you mean with "preferred 
> protocol"? Is the preferred protocol somewhere defined or is it the 
> preference of SP1?
> 
> Further I would write "_sips" instead of "sips" and "_sip" instead of 
> "sip" to make it clear that you mean the domain prefix for 
> the SRV lookup.
> 
> > 3.4 Using SRV Results 
> >     
> >    RFC 2782 describes the procedures on how to use and 
> interpret the 
> >    results obtained from the SRV query.  The target entry 
> of the SRV RRs 
> >    is looked up by querying the DNS for address records. 
> The SRV response 
> >    from DNS MAY also include A records with it which will 
> cut down on round
> 
> Again - also the NAPTR lookup may already return the SRV and 
> A record. 
> Having a additional section in the DNS response is not limited to the 
> SRV lookup.
> 
> 
> > 4.1 SPP1 Fails to Reach SPP2 
> >     
> >    A 503 error response is reported by the transaction 
> layer, or failure 
> >    can occur at the transport layer due to TCP disconnect 
> in connection, 
> >    ICMP error in UDP or time out at transport layer or SIP 
> layer timeout 
> >    when its not receiving any SIP response.  In such 
> situations, SPP1 
> >    tries a new SIP request transaction to the next available server 
> >    instance of SPP2 as determined by SRV RRs entry.  
> 
> 
> This is against RFC 3261 which says in case of 503 it should 
> not send to 
> an alternate server:
> 
> 21.5.4 503 Service Unavailable
>     ...
>     A client (proxy or UAC) receiving a 503 (Service 
> Unavailable) SHOULD
>     attempt to forward the request to an alternate server.  
> It SHOULD NOT
>     forward any other requests to that server for the 
> duration specified
>     in the Retry-After header field, if present.
> 
> 
> I further wonder about best practise for failover to another ingress 
> point of SP2. UDP timeout can take up to 32 seconds. TCP 
> timeout depends 
> on the OS. IMO this is quite long time for failover.
> 
> 1. Should this be described in this draft or maybe in the 
> callfows draft?
> 
> 2. What would be a good value until trying the next server? 
> 32 seconds 
> is too long. RFC 3261 allows redefinition of Timer T1. The 
> default value 
> is 500ms and should reflect the RTT to the next hop. Thus, if it is 
> knows that the RTT to the ingress point is 100ms, setting T1 to 100ms 
> allows faster failover (of course the Peering Proxy needs to support 
> setting of T1)
> 
> 
> > 5. Caching/TTL 
> >  
> >    SRV RRs have a TTL value based on which the SPP1 caches 
> the entry for 
> >    that duration and any further requests to the same 
> TARGET domain are 
> >    delivered to the cached server instance.  The TTL 
> recommended for SRV 
> 
> This sounds like the SPP1 must cache DNS results. Usually 
> applications 
> does not caches DNS as the caching is done by SP1's resolving name 
> server. IMO caching in the resolver must be fine too.
> 
> regards
> Klaus
> 
> -- 
> Klaus Darilion
> nic.at
> 
> _______________________________________________
> Speermint mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/speermint
> 

_______________________________________________
Speermint mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/speermint

---

From: Klaus Darilion <[email-masked]>
Date: Mon, 02 Oct 2006 18:22:08 +0200

> alternate server and not retry the server sending the 503 until after

Hi Mike!

Of course you are right. Looks like I read the RFC section too fast. 503 
is fine for causing failover.

regards
klaus