Re: [sipcore] Happy Eyeballs for SIP

["Asveren, Tolga" <[e-mail]>]

Inline...

Thanks,
Tolga

> -----Original Message-----
> From: Olle E. Johansson [mailto:[e-mail]]
> Sent: Friday, December 16, 2016 3:51 AM
> To: Asveren, Tolga <[e-mail]>
> Cc: Olle E Johansson <[e-mail]>; Dale R. Worley
> <[e-mail]>; [e-mail]
> Subject: Re: [sipcore] Happy Eyeballs for SIP
> 
> 
> > 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.
[TOLGA] Understood. As said before though, this could be achieved with a single RFC/progressive versions of drafts as well IMHO. OTOH, I wouldn’t cry much over having multiple RFCs either.  So, I guess this means "consensus reached".
> 
> 
> > 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.
[TOLGA] I think covering SRV records is critical. They are used widely in practice; for various reasons and in different models. I don’t think burying our head into sand would make this issue disappear. We may take a "practical" approach though. I think 90% of utility could be achieved by addressing 10% of complexity. Some extra freedom on ordering/selection of queries would go a long way.
In general, I am also baffled why platform related issues, e.g. interface selection, is something to be defined in a SIP related RFC. Granted, a solution should be implementable but defining how to select the right interface, e.g. which system call for a particular OS, does not belong to this RFC. Specification can talk about the need packets taking the correct/intended path but how this is achieved on a given platform is an implementation issue IMHO. But then, maybe the former is already what you meant.
> 
> 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.
[TOLGA] Maybe, I am not as optimistic as you though (especially when considering use of DTLS)
> 
> 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.
[TOLGA] Specification for UDP would mention about use of OPTIONS and maybe provide information about some use cases but the exact semantics of what/how is preferred shouldn’t be normatively defined.
> 
> 
> /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