Subject: [BEHAVE] Couple questions regarding RFC 5389 (STUN)

From: Todd Herman <[email-masked]>
Date: Fri, 21 Sep 2012 03:37:59 +0000

I have a few questions, clarifications really, regarding RFC 5389.  Is this the correct place to ask them?

Thanks,
Todd Herman

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 20 Sep 2012 22:49:43 -0700

> the correct place to ask them?

Yes.

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Todd Herman <[email-masked]>
Date: Fri, 21 Sep 2012 12:39:50 +0000

Awesome.  Section 7.2.1 of the RFC discusses using a Retransmission Timeout (RTO) calculated according to RFC 2988 with 2 minor alterations.  I have reviewed this section and RFC 2988 and I am having a difficult time getting it to work out as expected.  

The last paragraph in section 7.2.1 provides an example that says that if an RTO of 500ms is used the requests would be sent at 0, 500, 1500, 3500, 7500, 15500 and 31500.  Where are these values coming from?  I gather from the statement that RTO has already been calculated so that should mean we are not using the formulas in RFC 2988.  RFC 2988 does state that you should start with 500 ms for the first time anyway.  It is easy enough to see that those values are being backed off and seem to use the formula RTO = RTO * 2 + RTO but I don't see where this formula is mentioned in RFC 5389.

Could someone clear up this confusion  little for me please?

Todd Herman
Senior Software Engineer

> -----Original Message-----
> From: Marc Petit-Huguenin [mailto:[email-masked]]
> Sent: Friday, September 21, 2012 1:50 AM
> To: Todd Herman
> Cc: [email-masked]
> Subject: Re: [BEHAVE] Couple questions regarding RFC 5389 (STUN)
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> 
> iQIcBAEBCAAGBQJQW//1AAoJECnERZXWan7EyHgP/RXiw6deUa+hVrF0yiAPR
> VhD
> Q0xeXZaGkaDZ4GifKIgbIsG77VdMypBgXB/rTdYx6BbvrEhfzA5ZRH260Tm1u12
> F
> vYHNZ8tl7AeN1fOxZSvEYNj9li3qhmH81BCHdeNhWth1z+aFU08RdwiDB9m2dl
> 7H
> 2MBfyUAhg57JuTNdjrqtMmm4iHTiYAh2pwYGTP4bsb2st8JFohiHJrPdoF1wEEE
> E
> +uOffHeyvAPNitPAx9R1JmYwlheC78tsaSJDgc8EOv/XIg8nrYqm0wRYOPTALUp
> r
> 3oxCMojE0WDvQKNVbBnW9StnNclIoD1P7mTGYXA7dyXyPgWzEKoilERAlKn3
> 3AJh
> BfUJabNwmNYK5XUXm6JoQgLuxUzDwuhJGXQuwqYeAF8NfV0OTn45dIAx4G
> mZm1Pq
> XpilPST4hOPiLnut4p9rSJbgLtiIek5Fji2aUwua17QOdBPZvUxTmDvgI3kzYuYC
> LeJCQyct9bSzzVxe1wy7tp308ROKrzmQ4NEHXanCRxHXRcxtoJutdcaaRK6dijw
> D
> IYrobxvGfy6xC+NCSXj1ZBXM03G3H9A+bF08zGVq/QmF2unflqaSjvpv16XwLo
> BH
> U+jQXATKiOgZVxLHFjGvfw8KE3BO0RQgtjbddms+/TpJOVWT4l9zmmtC4lUMa
> OkU
> N4FvHklM5l2oztkOuCO9
> =z8GB
> -----END PGP SIGNATURE-----

---

From: Simon Perreault <[email-masked]>
Date: Fri, 21 Sep 2012 08:59:51 -0400

Le 2012-09-21 08:39, Todd Herman a écrit :
> The last paragraph in section 7.2.1 provides an example that says
> that if an RTO of 500ms is used the requests would be sent at 0, 500,
> 1500, 3500, 7500, 15500 and 31500.  Where are these values coming
> from?  I gather from the statement that RTO has already been
> calculated so that should mean we are not using the formulas in RFC
> 2988.  RFC 2988 does state that you should start with 500 ms for the
> first time anyway.  It is easy enough to see that those values are
> being backed off and seem to use the formula RTO = RTO * 2 + RTO but
> I don't see where this formula is mentioned in RFC 5389.

Section 7.2.1, second paragraph:

    A client SHOULD retransmit a STUN request message starting with an
    interval of RTO ("Retransmission TimeOut"), doubling after each
    retransmission.

That's it.

Value	Delta
0	
500     500
1500	1000
3500	2000
7500	4000
15500	8000
31500	16000

See? The delta doubles at each line.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Todd Herman <[email-masked]>
Date: Fri, 21 Sep 2012 14:09:09 +0000

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Simon Perreault
> Sent: Friday, September 21, 2012 9:00 AM
> To: [email-masked]
> > The last paragraph in section 7.2.1 provides an example that says that
> > if an RTO of 500ms is used the requests would be sent at 0, 500, 1500,
> > 3500, 7500, 15500 and 31500.  Where are these values coming from?  I
> > gather from the statement that RTO has already been calculated so that
> > should mean we are not using the formulas in RFC 2988.  RFC 2988 does
> > state that you should start with 500 ms for the first time anyway.  It
> > is easy enough to see that those values are being backed off and seem
> > to use the formula RTO = RTO * 2 + RTO but I don't see where this
> > formula is mentioned in RFC 5389.
> 

When I read that portion, I separated the "starting with an interval of RTO" from the "after each transmission" which gives you RTO = RTO * 2 for each iteration.  I do see that the delta doubles at each line but I am still missing something.  Where does the other portion of the value come from?  It appears to be RTO = RTO + delta but I don't see that in the description.  I apologize for being so obtuse here.  It is possible that I have been staring at these documents too long.  I don't want to just use the formula without fully understanding where the values are coming from.

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Todd Herman <[email-masked]>
Date: Fri, 21 Sep 2012 14:24:51 +0000

>     interval of RTO ("Retransmission TimeOut"), doubling after each

Ok.  I apologize for my earlier misunderstanding.  I think it is due to lack of sleep.  I was ignoring the fact that we are talking about points in time.  RTO starts at 500 and isn't changing.  The first retransmit happens after 500ms.  The next will happen after an additional RTO * 2 (or 1000) ms putting it at 1500ms.  And so on and so forth.  I totally get it now and apologize, again, for the slowness factor.

As an add-on question, am I understanding correctly that I only recalculate RTO (according to RFC 2988) once I have a successful transaction and calculate an actual RTT?

One more, would a retransmission timer apply to a specific transaction or to all transactions recently sent and awaiting replies?

I appreciate the assistance.  Simon, I also wanted to thank you specifically because of NUMB.  I have to build my own STUN/TURN client/server for a project and the use of NUMB as a test bed has been extremely helpful.

---

From: Simon Perreault <[email-masked]>
Date: Fri, 21 Sep 2012 15:37:57 -0400

Le 2012-09-21 10:24, Todd Herman a écrit :
> As an add-on question, am I understanding correctly that I only
> recalculate RTO (according to RFC 2988) once I have a successful
> transaction and calculate an actual RTT?

Yes.

> One more, would a retransmission timer apply to a specific
> transaction or to all transactions recently sent and awaiting
> replies?

I'm not exactly sure what you mean. Each transaction will be 
retransmitted independently from the others. So each one will have its 
own timer. But they should share their RTT estimate, as described in 
this excerpt:

    The value for RTO SHOULD be cached by a client after the completion
    of the transaction, and used as the starting value for RTO for the
    next transaction to the same server (based on equality of IP
    address).  The value SHOULD be considered stale and discarded after
    10 minutes.

> I appreciate the assistance.  Simon, I also wanted to thank you
> specifically because of NUMB.  I have to build my own STUN/TURN
> client/server for a project and the use of NUMB as a test bed has
> been extremely helpful.

Thanks, I'm glad that you like it! :)

Simon