Re: [sipcore] Happy Eyeballs for SIP

["Olle E. Johansson" <[e-mail]>]

> On 15 Dec 2016, at 20:58, Asveren, Tolga <[e-mail]> wrote:
> 
> Trying to summarize:
> 
> i- It is fine to target connection-oriented transport protocols first but I hope that does not imply that UDP never will be covered. I personally would favor a single RFC for all transports -initial versions of the draft can address/focus on connection-oriented ones- but could survive with multiple specifications as well.
At the last SIPcore IETF meeting we decided to split up the work in chewable bits. Separating connection oriented from the
much more complex connectionless area was one decision in order to make progress fast in the Connection oriented space.


> ii- I feel stronger about the need to address SRV records rather than limiting the solution to A/AAAA. Granted, an entity can do stupid things with the freedom of ordering of queries by also considering IP Address Family but that is a given with any new degree of freedom. It is a direct consequence thereof. Providing use cases/warnings about possible issues could address this concern in a satisfactory way IMHO.
If there is a problem, we need to work on it, but I would like to suggest that we limit the scope for each doc to get
it faster through the process.

We have a lot of related problems to cover, like selection of interfaces when we have multiple interfaces.

In regards to the current draft for connection-oriented SIP flows, I am not happy about copying a lot of text from the Happy Eyeballs RFC into this doc. 

Happy Eyeballs is a  large solution space and the important part of the RFC is the requirements - the solutions vary. 
Copying text from that RFC could mean we copy stuff that is out of scope and already old compared with today’s implementations and 
that we by accident limit the solution space for SIP, which would be unfortunate. The SIP solution for setting up a connection is in no 
way different from other protocols and thus I think we will be better off and have a smoother path to publication by just pointing to the Happy Eyeballs
RFC than starting to copy parts without us authors having current implementation experience.

Let’s keep the connection-oriented draft short and sweet and just get it to publication and then dive heads down into
UDP. That’s an area where no work has been done before (as far as I know) and we will propably end up producing an outbound-light
or something else. 

The implementation I work with currently send a simple OPTIONs without SDP to test both address
families and then select based on our preferences and responses. We do prefer IPv6 in this case, as IPv4 is hiding
behind an ugly carrier grade nat. As this is a mobile app, registration and calls happen within a short time and no 
flows are kept for long. Desktop phones have flows that goes on for a very long time and network properties may
change during that time, so we need more regular discovery.


/O
> 
> Thanks,
> Tolga
> 
>> -----Original Message-----
>> From: Dale R. Worley [mailto:[e-mail]]
>> Sent: Thursday, December 15, 2016 2:16 PM
>> To: Asveren, Tolga <[e-mail]>
>> Cc: [e-mail]
>> Subject: Re: [sipcore] Happy Eyeballs for SIP
>> 
>> "Asveren, Tolga" <[e-mail]> writes:
>>>> However, we decided to
>>>> not handle SRV in this tranche because a comprehensive approach to
>>>> SRV is complicated and nobody has yet proposed a solution that
>>>> promises to meet the desiderata, viz.:
>>>> 
>>>> - achieve the Happy Eyeballs effect, that is, traffic will be very
>>>>  rarely delayed by unreachability of one or more of the targets
>>>> 
>>>> - achieve the specified effect of SRV, that is, among the set of targets
>>>>  which are reachable, over the long run, the traffic will be
>>>>  distributed among them according to the specified priorities and
>>>>  weights in the SRV records
>> 
>>> [TOLGA] I understand that "perfect outcome" may be hard to describe
>>> -let alone to achieve- especially considering various deployment
>>> models/expectations. OTOH, I would think that allowing some freedom in
>>> terms of ordering could be all what needs to be mentioned in the
>>> specification, e.g.
>> 
>>> Rather than:
>> 
>>> One ought to use the SRV records according to their weight/priority
>>> where eventually only one of them is the winner and is resolved
>> 
>> I'm not sure that "only one of [the SRV records] ... is resolved" is correct.  If
>> there are two SRV records and, for the one with the lowest priority value,
>> the address(es) for the target name cannot be contacted, the client is
>> required to attempt to contact the address(es) for the target name of the
>> other SRV record.
>> 
>>> This:
>> 
>>> One may resolve all/a sub-set of available SRV records by also
>>> considering IP Address Family and IP Address Family can be also
>>> considered for the order of the queries
>>> 
>>> I can provide text/edit the document if we can reach a
>>> conclusion/consensus on this point.
>> 
>> I suspect that allowing the client unlimited authority to reorder the target
>> addresses based on IP address family will allow behaviors that we do not
>> want to allow.  In particular, if the SRV records give one IP address family
>> over the other family, and the client can contact both addresses, we want
>> the client to respect that declared priority.  (This is a variation on the example
>> in RFC 7984.)
>> 
>>>>> I am not sure
>>>>> what the right interpretation should be here but it is not
>>>>> well-defined to say the least. To me, it seems like RFC7984 should
>>>>> be updating RFC3263 normatively in this aspect as well -to promote
>>>>> the
>>>>> RFC7984 defined behavior-. And IMHO it would be up to the
>>>>> Happy-Eyeballs draft to define how addresses from multiple SRV
>>>>> Records should be used. Cases, where a dual-stack entity does not
>>>>> know whether
>>>>> IPv4/IPv6 is preferred and multiple SRV records are used for
>>>>> different address families on different servers should be covered as
>> well.
>>>> 
>>>> Can you give an example where the procedures of RFC 2782 aren't
>>>> sufficient to resolve this problem?
>> 
>>> [TOLGA]  "Usage Rules" section of RFC2782 seem to imply:
>> 
>>> i- A list is prepared by querying all SRV records. Queries are
>>> performed by the priority/weight based ordering.
>> 
>>> ii- And then there is "freedom" in terms of selecting the server to
>>> actually use.
>> 
>> The freedom allowed by RFC 2782 is limited.  Actually, the only variation
>> allowed in the order of contacting the addresses is due to the use of random
>> numbers in selecting between records of the same priority.
>> (section "The format of the SRV RR" item "Weight")
>> 
>>> I think i- is where some improvement could be useful in the context of
>>> happy-eyeballs. The IP Address Family can be used as a third parameter
>>> -in addition to priority/weight- when ordering DNS queries. Granted,
>>> one may argue that all queries can be performed in parallel but still
>>> some clarification text in the specification could be a good idea to
>>> highlight this and prevent any confusion.
>> 
>> Remember that only one DNS query is needed to obtain *all* the SRV
>> records for a particular domain name and transport.
>> 
>>>> The *concept* of Happy Eyeballs can, should, and will be applied to
>>>> UDP, but the *details* are going to be considerably different from the
>> details for TCP.
>>>> For the first tranche, we are attempting to stay near what has been
>>>> done for HTTP, so we are limiting the scope to connection-oriented
>> protocols.
>> 
>>> [TOLGA] I think one issue was regarding the "probing" for UDP. With
>>> TCP, connection establishment provides information about the quality
>>> of the connection toward the server. Why not using OPTIONS for UDP? It
>>> wouldn't change the "SIP state" and wouldn't cause any distraction to
>>> end users/devices.
>> 
>> Yes, that would work.  But as I said, UDP is not included in this tranche.
>> 
>> Dale
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore