Subject: Re: [sipcore] Happy Eyeballs: Targets

From: Brett Tate <[email-masked]>
Date: Tue, 28 Jun 2016 12:29:26 -0400

Hi,

Thanks for the response; reply is inline.

> > The issue with using a smaller T1 value is that it doesn't
> > just impact the desired timer.  For instance, it can cause
> > more retries.  Because of this, the draft might want to
> > specify allowing the specific smaller timers in a way which
> > doesn't rely upon a smaller T1.
> >
> > If it matters, RFC 3261 section 17.1.1.2 has normative
> > statements concerning the topic of lowing T1.
>
> It seems to me that the core concept of that section is
> "T1 is an estimate of the round-trip time (RTT)".
> And while the average RTT over the global Internet is nearly
> 500ms, the RTT to places that expect a lot of traffic
> seems to be 100ms or less.  (I expect RTT on carrier-managed
> networks to be even less.)  So I don't see cutting the
> default T1 as contravening that section.

Although this draft can update it if needed, RFC 3261 section 17.1.1.2
paragraph four was the text of potential concern since it looks like an
attempt to limit where T1 can be lowered.

"Elements MAY (though it
is NOT RECOMMENDED) use smaller values of T1 within closed, private
networks that do not permit general Internet connection.  T1 MAY be
chosen larger, and this is RECOMMENDED if it is known in advance
(such as on high latency access links) that the RTT is larger."

> True, that does increase the number of retries, but that seems
> to be the correct change if it's true that if you don't see a
> response in 100ms, it is more likely that the request was lost
> than that it is delayed in transit.

It seems like the extra retries would be an unnecessary burden upon the
next hop.  However, I guess that it depends upon if more concerned with 1)
dropped packets or 2) the retries increasing the frequency of devices
becoming overloaded.

Unless this draft updates the RFC 4320 behavior, there can be many retries
before the next hop can return 100 for non-INVITE requests.

As mentioned, the smaller T1 value would not just impact the desired
timers.  It would impact other letter timers within RFC 3261 and RFC 6026
such as Timer L, Timer M, Timer H, Timer J, and as mentioned Timer A,
Timer E, and Timer G.  Should these timers really be reduced?  For
instance, is it acceptable for UAS to use T1 of 100ms when the UAC and
intermediaries are using T1 of 500ms?