[sipcore] comments on draft-ietf-sipcore-dns-dual-stack-02

[🔓Dan Wing <[e-mail]>]

Adam encouraged me to look at draft-ietf-sipcore-dns-dual-stack-02, and I had a few suggestions.

Towards the end of the Introduction, it says:

  The procedures described herein
  are such that a dual-stack client SHOULD look up both A and AAAA
  records in DNS and then select the best way to set up a network flow.
  The details of how the latter is done is considered out of scope for
  this document.

I guess "network flow" means the SIP communications to the SIP server?  Is there a better term than "network flow" that could be used, so that nobody can confuse the "network flow" with the RTP session?

Section 4.1 says:

  Happy Eyeballs [RFC6555] has proven that looking up the "A or AAAA
  record" is not an effective practice for dual-stack clients and that
  it can add significant connection delay and greatly degrade user
  experience.

What we know is that 30 second long TCP connection timeouts are harmful to user experience.    Happy Eyeballs is but one pragmatic solution.  I do not agree that Happy Eyeballs proved there is a connection delay problem due to A lookups or with AAAA lookups.  What I think draft-ietf-sipcore-dns-dual-stack is trying to say is perhaps something like this:

 "Happy Eyeballs [RFC6555] works around connectivity delays to the OS's preferred address family (usually IPv6), so that the client suffers a connectivity delay that is only slightly worse than an single-stack host.  Without Happy Eyeballs, a client could suffer a 30 second delay to its preferred address family."


I noted that draft-ietf-sipcore-dns-dual-stack does not actually resolve this connectivity problem in its normative text; it seems solely worried about DNS lookups.  I admit that I haven't been following draft-ietf-sipcore-dns-dual-stack, but was it a conscious design or scoping decision to not worry about the IPv6 or IPv4 path to the SIP server, and just worry about DNS answers?



The actual recommendation at end of section 4.1 only says:

     The dual-stack client SHOULD perform an A and AAAA record lookup
     of the domain name and add the respective IPv4/IPv6 addresses to
     the list of IP addresses to be contacted.

but it doesn't say if A or AAAA should be placed at the beginning of the list, end of the list, or scattered randomly.  It probably matters, especially if we envision a long list of AAAA and long list of A records, and we also envision an outage of one address family.



I noticed that sections 4.1 and 4.2 make no recommendation for how quickly attempts should be made to contact the SIP server over IPv4 or IPv6, and does not discuss the harm -- or lack of harm -- of a server receiving identical SIP messages during that time.  I expect nothing harmful happens if an implementation decided to be really aggressive with its use of IPv6 and IPv4, but it would be good to remind implementors of harm or non-harm of sending messages (aggressively) which might be received multiple times.  Happy Eyeballs (RFC6555) doesn't worry about that problem because Happy Eyeballs is just concerned with TCP connection establishment time.  With SIP signaling over UDP, we don't get a 'connection' first.  Should draft-ietf-sipcore-dns-dual-stack discuss UDP and TCP separately, and should implementations do something more like RFC6555 if they are doing SIP over TCP, and something different if doing SIP over UDP?


Section 4.2 says:

  When indicating address family preference through SRV, IPv4-only and/
  or IPv6-only clients should be prepared to handle SRV record sets
  that don't resolve into an ip address in the address family used by
  that client.

I believe the "should" should be RFC2119 capitalized (so that it is normative), and I also believe it needs to be MUST, because failure to handle multiple SRV record sets will cause interoperability problems, won't it?


Next sentence of Section 4.2 says:

  In such a case, the client should simply proceed to the
  next priority and try the hostnames in the alternate address family.

s/alternate address family/supported address family/

-d