Subject: [Ietf-behave] STUN retransmission timers

From: Pasi Sarolahti <[email-masked]>
Date: Tue, 29 Aug 2006 21:25:42 -0500 (CDT) (envelope-from [email-masked])

RFC3489bis authors & everyone,

I was browsing through draft-ietf-behave-rfc3489bis-04, and section 7.1
on STUN retransmission timers caught my eye, particularly the
requirement that "Clients SHOULD retransmit the request starting with an
interval of 100ms, doubling every retransmit until the interval reaches
1.6 seconds." -- to me this seems like a way too small value for a
retransmission timeout. There are many paths where the round-trip time
easily goes over 100ms, such as with many wireless network technologies
(for example GPRS/GSM) or satellite links, etc.

I think it would be useful to be consistent with values that TCP uses
(recommended 1000ms minimum timeout [RFC 2988]), or what SIP uses
(default 500ms [RFC 3261]). Thoughts?

Regards,
- Pasi

Attachment:
signature.asc

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 30 Aug 2006 13:50:09 -0500 (CDT) (envelope-from [email-masked])

I think there's a bit of a paradox at work here:

If you have short retransmission timers, as you point out, the behavior
in a wireless network is likely to be poor as many retransmissions will
serve no purpose but to clog the access network up with traffic that
provides no value.

However, if you increase the retransmission timers, other uses of STUN
(like ICE) will suffer from increased call setup delay (which is already
challenging in many deployment environments).

Regards,
Brian

> -----Original Message-----
> From: ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx 
> [mailto:ietf-behave-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of 
> Pasi Sarolahti
> Sent: Tuesday, August 29, 2006 9:26 PM
> To: ietf-behave@xxxxxxxxxxxxxxxxxxx
> Subject: [Ietf-behave] STUN retransmission timers
> 
> I was browsing through draft-ietf-behave-rfc3489bis-04, and 
> section 7.1 on STUN retransmission timers caught my eye, 
> particularly the requirement that "Clients SHOULD retransmit 
> the request starting with an interval of 100ms, doubling 
> every retransmit until the interval reaches
> 1.6 seconds." -- to me this seems like a way too small value 
> for a retransmission timeout. There are many paths where the 
> round-trip time easily goes over 100ms, such as with many 
> wireless network technologies (for example GPRS/GSM) or 
> satellite links, etc.
> 
> I think it would be useful to be consistent with values that 
> TCP uses (recommended 1000ms minimum timeout [RFC 2988]), or 
> what SIP uses (default 500ms [RFC 3261]). Thoughts?
> 
> Regards,
> - Pasi
> 
>

---

From: Pasi Sarolahti <[email-masked]>
Date: Wed, 30 Aug 2006 15:41:30 -0500 (CDT) (envelope-from [email-masked])

> challenging in many deployment environments).

(if there is a packet loss)

Yep, I see the point. But taking more principled angle, some working
groups make a big deal about not exceeding the initial sending rate and
retransmission timeout values considered to be TCP-friendly. Is it ok
for some IETF protocols to shortcut these principles and implement their
own faster (re)transmission mechanisms over UDP? If yes, ok (but in that
case it would be useful to lay out the reasoning somewhere why, and in
which cases, it is ok).

Ideally a retransmission timer should somehow take the current RTT into
account to be even close to appropriate timeout values -- and then one
would be one step closer to re-implementing TCP :-).

- Pasi

Attachment:
signature.asc

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 31 Aug 2006 20:01:09 -0500 (CDT) (envelope-from [email-masked])

> RFC3489bis authors & everyone,

As rfc3489bis co-author:

Based on your thread and Brian's recent thread ("Time to add
mapping/filtering entries"), I thought about rfc3489bis and ICE's
interaction with it.

ICE makes two significant uses of STUN that are interesting to BEHAVE.  The
first is the 'classic STUN' usage ("Binding Discovery" in
-behave-rfc3489bis) -- learn your public IP address and UDP port.  To avoid
the problem Cullen described (where NATs seem to 'forget' to create
bindings) those binding discovery STUN packets to the STUN server(s) need to
be paced.

The second interesting ICE usage is its connectivity checks ("Connectivity
Check" in -behave-rfc3489bis).

ICE's connectivity checks don't need to be paced to be gentle for the same
reason, because ICE's connectivity checks don't create new NAT bindings
(pedantic readers know that there are some exceptional configurations where
ICE's connectivity checks do create a new NAT binding).  Rather, ICE's
connectivity checks only using existing bindings and change the NAT's
filtering (if the NAT does do filtering).  

I suggest -behave-rfc3489bis should break out the retransmission rules into
per-usage recommendations.

Of the usages defined in -behave-rfc3489bis,
  1.  Binding Discovery
  2.  Connectivity Check  
  3.  NAT Keepalives  
  4.  Short-Term Password 
here are some thoughts on retransmit timers:

1. Binding Discovery:  it doesn't harm interoperability if one STUN
   client uses 100ms and another STUN client uses 2000ms.  It harms
   call setup time, of course, but presumably the clients were
   configured with those retransmit timers on purpose -- someone knew
   the network was fast (100ms) or the network was slow but had very
   little loss (2000ms).  After the first STUN check, the
   retransmission timer could be adjusted.  Note that for ICE, you do
   a STUN check for your RTP and for your RTCP port separately for
   each media stream.  So if you're doing audio and video you will
   send 4 STUN packets from 4 different local ports, paced 50ms apart
   (to avoid the problem Cullen described).  If you receive a STUN
   response for the first one in 20ms you know the RTT and processing
   time of the STUN server is 20ms.  We use that knowledge to our
   advantage in determining the retransmission timer for the other 3
   outstanding STUN transactions.  Each of them should come back 20ms
   after we sent their request.  If we don't see the response in 20ms,
   and we wanted to be aggressive, we could send another request in
   max(RTT,50ms).

2. Connectivity check:  connectivity checks don't occur until you know
   the peer's IP address and codecs.  That provides enough information
   about the expected bandwidth that ICE can stay below that bandwidth
   while performing its connectivity checks.

3. NAT Keepavlies:  the initial RTT used by TCP SYNs seems reasonable
   (WinXP seems to wait 2 seconds, for whatever that's worth.  RFC2988
   seems to recommend a value less than 3 seconds).  From there, the
   RTT of previous successful NAT keepalives can be useful to adjust
   the retransmit value of subsequent NAT keepalives.

4. Short-Term Password:  This is usually the same server as (1), so
   apply the same rules as (1).

-d

---

From: Lars Eggert <[email-masked]>
Date: Fri, 1 Sep 2006 10:40:37 -0500 (CDT) (envelope-from [email-masked])

Hi,

as an individual contributor, let me echo Pasi's concerns with  
regards to sending the first retransmission after 100ms. (I do need  
to read up on the details of the latest STUN version though.)

On Sep 1, 2006, at 3:00, Dan Wing wrote:
ICE's connectivity checks don't need to be paced to be gentle for  
the same
reason, because ICE's connectivity checks don't create new NAT  
bindings

The potential issue is with causing additional traffic on long,  
narrow paths, not with causing load on the NAT (but that might be an  
issue, too).

   little loss (2000ms).

Right, but the current draft simply says "clients SHOULD retransmit  
the request starting with an interval of 100ms", irrespective of the  
path. Maybe it should say something like "clients SHOULD retransmit  
the request starting with an interval off f(RTT), or Y seconds if the  
RTT is unknown." TCP uses 3 seconds for Y per RFC1122; see RFC2988  
for f().

Lars
--
Lars Eggert                                     NEC Network Laboratories

Attachment:
smime.p7s

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 1 Sep 2006 11:18:48 -0500 (CDT) (envelope-from [email-masked])

Dan,

I see where you are headed with this, I think it's a good start.

With #2, how would bandwidth affect ICE connectivity checks? Are you
assuming that bandwidth will guarantee a certain latency budget as well?

Regards,
Brian 

> From: Dan Wing [mailto:dwing@xxxxxxxxx] 
> Sent: Thursday, August 31, 2006 8:01 PM
> Cc: Stucker, Brian (RICH1:B620); 'Pasi Sarolahti'
> Subject: RE: [Ietf-behave] STUN retransmission timers
> 
> mapping/filtering entries"), I thought about rfc3489bis and 
> ICE's interaction with it.
> 
> 
> ICE makes two significant uses of STUN that are interesting 
> to BEHAVE.  The first is the 'classic STUN' usage ("Binding 
> Discovery" in
> -behave-rfc3489bis) -- learn your public IP address and UDP 
> port.  To avoid the problem Cullen described (where NATs seem 
> to 'forget' to create
> bindings) those binding discovery STUN packets to the STUN 
> server(s) need to be paced.
> 
> The second interesting ICE usage is its connectivity checks 
> ("Connectivity Check" in -behave-rfc3489bis).
> 
> ICE's connectivity checks don't need to be paced to be gentle 
> for the same reason, because ICE's connectivity checks don't 
> create new NAT bindings (pedantic readers know that there are 
> some exceptional configurations where ICE's connectivity 
> checks do create a new NAT binding).  Rather, ICE's 
> connectivity checks only using existing bindings and change 
> the NAT's filtering (if the NAT does do filtering).  
> 
> I suggest -behave-rfc3489bis should break out the 
> retransmission rules into per-usage recommendations.
> 
>

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 1 Sep 2006 12:13:42 -0500 (CDT) (envelope-from [email-masked])

Brian,

> assuming that bandwidth will guarantee a certain latency 

No, I'm not assuming any relationship between bandwidth and latency.  There
is the extreme of running VoIP over satellite, and the extreme that we could
negotiate G.711 but be on opposite sides of the planet.

Rather, I'm saying that if the bandwidth of the negotiated codec is 100kbps,
it would be prudent for ICE's connectivity checks to not exceed 100kbps.
Networks with strict QoS schedulers may drop packets that exceed the
expected bandwidth (PacketCable, most notably; I expect IMS would have
similar behavior).

-d

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 1 Sep 2006 12:24:50 -0500 (CDT) (envelope-from [email-masked])

Ok, makes sense.

In terms of wireless, there's a bit of trick that may have to be played
as QoS may not be stable yet at the time that an answer to an offer
comes back while all of the elements on the signaling path figure out
what they want to do with the SDP being exchanged in terms of adjusting
the final QoS granted.

Also, with mobility networks, there is the possibility that the path
that the early packets take is different than ones that the final bearer
path will take. So, just because the SDP is good for 100kbps, it does
not mean that the packets going between endpoints will get this type of
treatment during early stages of the session setup process (right when
connectivity checks would be getting performed) or there may be a race
condition between the route optimization used and the connectivity
checks doing their thing.

Regards,
Brian

> Sent: Friday, September 01, 2006 12:14 PM
> To: Stucker, Brian (RICH1:B620); ietf-behave@xxxxxxxxxxxxxxxxxxx
> Cc: 'Pasi Sarolahti'
> No, I'm not assuming any relationship between bandwidth and 
> latency.  There is the extreme of running VoIP over 
> satellite, and the extreme that we could negotiate G.711 but 
> be on opposite sides of the planet.
> 
> Rather, I'm saying that if the bandwidth of the negotiated 
> codec is 100kbps, it would be prudent for ICE's connectivity 
> checks to not exceed 100kbps.
> Networks with strict QoS schedulers may drop packets that 
> exceed the expected bandwidth (PacketCable, most notably; I 
> expect IMS would have similar behavior).
> 
> -d
> 
> > > ICE makes two significant uses of STUN that are interesting to 
> > > BEHAVE.  The first is the 'classic STUN' usage ("Binding 
> Discovery" 
> > > in
> > > -behave-rfc3489bis) -- learn your public IP address and 
> UDP port.  
> > > To avoid the problem Cullen described (where NATs seem to 
> 'forget' 
> > > to create
> > > the same reason, because ICE's connectivity checks don't 
> create new 
> > > NAT bindings (pedantic readers know that there are some 
> exceptional 
> > > configurations where ICE's connectivity checks do create 
> a new NAT 
> > > binding).  Rather, ICE's connectivity checks only using existing 
> > > bindings and change the NAT's filtering (if the NAT does do 
> > > filtering).
> > > 
> > > I suggest -behave-rfc3489bis should break out the retransmission 
> > > rules into per-usage recommendations.
> > > 
> > >

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 1 Sep 2006 12:57:21 -0500 (CDT) (envelope-from [email-masked])

> Ok, makes sense.
> 
> In terms of wireless, there's a bit of trick that may have to be
> played as QoS may not be stable yet at the time that an answer to an
> offer comes back while all of the elements on the signaling path
> figure out what they want to do with the SDP being exchanged in
> terms of adjusting the final QoS granted.
>
> that the early packets take is different than ones that the final
> bearer path will take.  So, just because the SDP is good for
> 100kbps, it does not mean that the packets going between endpoints
> will get this type of treatment during early stages of the session
> setup process (right when connectivity checks would be getting
> performed) or there may be a race condition between the route
> optimization used and the connectivity checks doing their thing.

ICE's connectivity checks don't need to be QoS'd like the forthcoming RTP
packets.  Packet loss will interfere with ICE, though.

Ignoring ICE's connectivity checks, wouldn't the behavior you describe cause
problems with real media packets, too, if they are sent before these
additional steps are performed?

-d

> > > assuming that bandwidth will guarantee a certain latency 
> budget as 
> > > well?
> >

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 1 Sep 2006 13:10:26 -0500 (CDT) (envelope-from [email-masked])

Dan,

I'm not of the opinion that ICE connectivity checks need to be QoS'd
like RTP packets. However, routing of packets during the early stages of
call setup in a wireless environment are likely to encounter vastly
different latency budgets as the RTP packets that follow when the call
setup has been completed. So, you're not necessarily losing packets.
However, if the endpoint is retransmitting too quickly it may
mis-identify an endpoint as not being usable because it's confused
latency with unreachability. Alternately, you'd could be spamming the
network with connectivity checks due to impatience.

To answer your second question, yes. It could. However, the problem is
not likely to be as severe because in most wireless settings early media
is middle-to-end and not end-to-end. The middle typically has more
control and awareness of what's going on with the bearer and fewer hops
to complete any round-trips necessary.

Regards,
Brian

> Sent: Friday, September 01, 2006 12:57 PM
> > figure out what they want to do with the SDP being 
> exchanged in terms 
> > of adjusting the final QoS granted.
> >
> > bearer path will take.  So, just because the SDP is good 
> for 100kbps, 
> > it does not mean that the packets going between endpoints will get 
> > this type of treatment during early stages of the session setup 
> > process (right when connectivity checks would be getting
> ICE's connectivity checks don't need to be QoS'd like the 
> forthcoming RTP packets.  Packet loss will interfere with ICE, though.
> 
> Ignoring ICE's connectivity checks, wouldn't the behavior you 
> describe cause problems with real media packets, too, if they 
> are sent before these additional steps are performed?
> 
> -d
> 
> 
> > Regards,
> > Brian
> > 
> > > No, I'm not assuming any relationship between bandwidth 
> and latency.  
> > > There is the extreme of running VoIP over satellite, and 
> the extreme 
> > > that we could negotiate G.711 but be on opposite sides of the 
> > > planet.
> > > 
> > > Rather, I'm saying that if the bandwidth of the 
> negotiated codec is 
> > > 100kbps, it would be prudent for ICE's connectivity checks to not 
> > > exceed 100kbps.
> exceed the 
> > > expected bandwidth (PacketCable, most notably; I expect IMS would 
> > > have similar behavior).
> > > 
> > > -d
> > >

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 1 Sep 2006 14:43:29 -0500 (CDT) (envelope-from [email-masked])

> setup has been completed.

Things like policy-based routing and DSCP-aware routing can also cause
differences; in fact, they can cause the ICE packets to succeed where
the RTP packets will fail.  I don't think ICE-10 provides guidance on
DSCP marking of its packets, but it probably should:  they should 
receive the same DSCP marking as the RTP packets.

> So, you're not necessarily losing packets.
> latency with unreachability.

The timer value for unreachable isn't directly tied to how quickly
you retransmit.  You might declare an endpoint unreachable at a 
fixed 1000ms, but inside of that second you could have transmitted
and retransmitted several connectivity checks.

> Alternately, you'd could be spamming the

If you're going to be sending 100kbps as soon as the call is answered
anyway, 100kbps of connectivity checks isn't awful.  If you're going
to be sending 10kbps as soon as the call is answered, 100kbps of
connectivity checks could very well be awful.  

> not likely to be as severe because in most wireless settings 
> early media is middle-to-end and not end-to-end. The middle 
> typically has more control and awareness of what's going on 
> with the bearer and fewer hops to complete any round-trips 
> necessary.

As in draft-stucker-sipping-early-media-coping-01, right?

-d

---

From: "Brian Stucker" <[email-masked]>
Date: Fri, 1 Sep 2006 16:13:30 -0500 (CDT) (envelope-from [email-masked])

> Sent: Friday, September 01, 2006 2:43 PM
> > like RTP packets. However, routing of packets during the 
> early stages 
> > of call setup in a wireless environment are likely to 
> encounter vastly 
> Things like policy-based routing and DSCP-aware routing can 
> also cause differences; in fact, they can cause the ICE 
> packets to succeed where the RTP packets will fail.  I don't 
> think ICE-10 provides guidance on DSCP marking of its 
> packets, but it probably should:  they should receive the 
> same DSCP marking as the RTP packets.
> 
> The timer value for unreachable isn't directly tied to how 
> quickly you retransmit.  You might declare an endpoint 
> unreachable at a fixed 1000ms, but inside of that second you 
> could have transmitted and retransmitted several connectivity checks.

Hmm.. I thought it was tied to number of retransmissions or time
(whichever is satisfied first). I'll have to look for that in -10.

> 
> > Alternately, you'd could be spamming the network with connectivity 
> > checks due to impatience.
> 
> If you're going to be sending 100kbps as soon as the call is 
> answered anyway, 100kbps of connectivity checks isn't awful.  
> If you're going to be sending 10kbps as soon as the call is 
> answered, 100kbps of connectivity checks could very well be awful.  

Assuming you're going to get 100kbps. It's a concern that shouldn't be
dismissed out of hand.

> > not likely to be as severe because in most wireless settings early 
> > media is middle-to-end and not end-to-end. The middle typically has 
> > more control and awareness of what's going on with the bearer and 
> > fewer hops to complete any round-trips necessary.
> 

Yes, I need to put that into the -02 revision.

> > > describe cause problems with real media packets, too, if they are 
> > > sent before these additional steps are performed?
> > > 
> > > -d
> > > 
> > > 
> > > > Regards,
> > > > Brian
> > > > 
> > > > > > >    outstanding STUN transactions.  Each of them 
> should come
> > > > > > back 20ms

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 1 Sep 2006 16:24:29 -0500 (CDT) (envelope-from [email-masked])

> (whichever is satisfied first).  I'll have to look for that in -10.

That is what -10 says.  However, this whole thread was about the
validity of the 100ms STUN retransmit timer.  So I'm trying to tease
out what works best from the perspective of success through NATs, 
and (to a lesser extent) what would work best for ICE.

-d

> > > > > > > >    client uses 100ms and another STUN client 
> uses 2000ms. 
> > > > > >  It harms
> > > > > > > >    retransmission timer could be adjusted.  
> Note that for
> > > > > > > ICE, you do
> > > > > > > >    send 4 STUN packets from 4 different local 
> ports, paced
> > > > > > > 50ms apart
> > > > > > > >    response for the first one in 20ms you know 
> the RTT and
> > > > > > > processing
> > > > > > > >    the peer's IP address and codecs.  That 
> provides enough
> > > > > > > information
> > > > > > > > 3. NAT Keepavlies:  the initial RTT used by TCP 
> SYNs seems
> > > > > > > reasonable
> > > > > > > >    seems to recommend a value less than 3 
> seconds).  From
> > > > > > there, the

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 1 Sep 2006 17:03:26 -0500 (CDT) (envelope-from [email-masked])

> narrow paths, not with causing load on the NAT (but that might be an  

What do you mean by 'additional'?  Any traffic sent is additional 
compared to sending no traffic at all, and ICE needs to send some
packets.

> the request starting with an interval off f(RTT), or Y 
> seconds if the RTT is unknown." TCP uses 3 seconds for Y per 
> RFC1122; see RFC2988 for f().

Thanks for the pointers.  STUN is more similar to DNS than to TCP,
and I see that RFC1123 (page 77) recommends an initial minimum RTT 
of 5 seconds:

    >  (5)  When a DNS server or resolver retries a UDP query,
    >       the retry interval SHOULD be constrained by an
    >       exponential backoff algorithm, and SHOULD also have
    >       upper and lower bounds.
    >
    >       IMPLEMENTATION:  A measured RTT and variance (if
    >       available) should be used to calculate an initial
    >       retransmission interval.  If this information is not
    >       available, a default of no less than 5 seconds should
    >       be used.  Implementations may limit the
    >       retransmission interval, but this limit must exceed
    >       twice the Internet maximum segment lifetime plus
    >       service delay at the name server.

-d

---

From: Lars Eggert <[email-masked]>
Date: Sat, 2 Sep 2006 03:47:36 -0500 (CDT) (envelope-from [email-masked])

Hi, Dan,

On Sep 2, 2006, at 0:03, Dan Wing wrote:

"Additional" in the sense of sending out the first retransmission  
before the original transmission has had a chance to reach the  
destination (on a path with a one-way delay > 100ms).

If a host has multiple bindings over a long, narrow path, this may  
add up.

Thanks for the pointer. DNS is even more conservative.

Lars

Attachment:
smime.p7s

---

From: "Dan Wing" <[email-masked]>
Date: Sat, 2 Sep 2006 11:42:05 -0500 (CDT) (envelope-from [email-masked])

> If a host has multiple bindings over a long, narrow path, this may  

ICE-10 only tests one media line at a time, so it shouldn't add up 
as quickly as previous versions of ICE.  

> Thanks for the pointer. DNS is even more conservative.

I was surprised to see DNS recommended such a high initial RTT,
especially that it's higher than TCP's and your DNS server is
most typically near you.

-d

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 2 Sep 2006 20:43:44 -0500 (CDT) (envelope-from [email-masked])

I must say I don't really like the idea too much of having to adjust the 
STUN transaction timers on a usage-by-usage basis. Certainly for SIP we 
have not advocated different timers for SIP transactions for INVITE vs. 
SUBSCRIBE, though the two of them both have quite different requirements 
around latency.

I think it makes more sense to try to tune these as a function of RTT. 
Lars suggested:

clients SHOULD retransmit  the request starting with an interval off f(RTT), or Y seconds if the  RTT is unknown." TCP uses 3 seconds for Y per RFC1122; see RFC2988  for f(). 

We'll then get into the issue about whether 3s is a reasonable RTT 
assumption in any network where we're using STUN. I will note that any 
network with a 3s RTT is going to stink for voip...

-Jonathan R.

Dan Wing wrote:

As rfc3489bis co-author:

-d
_______________________________________________
Ietf-behave mailing list
Ietf-behave@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/ietf-behave

--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@xxxxxxxxx                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 3 Sep 2006 00:52:28 -0500 (CDT) (envelope-from [email-masked])

I agree learning the RTT is useful, if you can estimate the RTT to that
host:  the RTT to the STUN server isn't related to the RTT for connectivity
checks.  The RTT should only be learned on a per-host basis or perhaps a
per-"connection" basis.

-d

> From: Jonathan Rosenberg [mailto:jdrosen@xxxxxxxxx] 
> Sent: Saturday, September 02, 2006 6:44 PM
> To: Dan Wing
> Cc: ietf-behave@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Ietf-behave] STUN retransmission timers
> 
> > clients SHOULD retransmit  the request starting with an 
> interval off f(RTT), or Y seconds if the  RTT is unknown." 
> TCP uses 3 seconds for Y per RFC1122; see RFC2988  for f(). 
> 
> to BEHAVE.  The
> port.  To avoid
> the NAT's

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 5 Sep 2006 18:09:20 -0500 (CDT) (envelope-from [email-masked])

Just as a comment watching this thread ...

I will note that the PWE work allows an unlimited amount of  
bandwidth, has no backoff, is not TCP rate friendly, can be expected  
over all sorts of IP networks but most importantly for the discussion  
here ... did not seem to have issues with this in IETF LC and was  
approved by IESG.

For the most part, it does not seem like there are practical ways for  
a client to estimate it's RTT without doing something more or less  
like STUN. So we could say that it should be configurable and that  
the default should be some value. Back of the envelope looks like ICE  
won't work if we set the default to 3 seconds. I seem to recall that  
we spent a long time on this argument when we did the STUN RFC. If we  
were going to redo that conversation, I would want us to have some  
good logic on why this was a problem worth solving. It may be that we  
need to scope where STUN is used to be places where this STUN induced  
portion of the congestion problem would be a drop in the bucket  
compared to the RTP over UDP problem.

Cullen (with my individual hat on)

On Sep 2, 2006, at 6:43 PM, Jonathan Rosenberg wrote:

I must say I don't really like the idea too much of having to  
adjust the
STUN transaction timers on a usage-by-usage basis. Certainly for  
SIP we
have not advocated different timers for SIP transactions for INVITE  
vs.
SUBSCRIBE, though the two of them both have quite different  
requirements

around latency.

clients SHOULD retransmit  the request starting with an interval  
off f(RTT), or Y seconds if the  RTT is unknown." TCP uses 3  
seconds for Y per RFC1122; see RFC2988  for f().

-Jonathan R.

Dan Wing wrote:

As rfc3489bis co-author:

BEHAVE.  The

first is the 'classic STUN' usage ("Binding Discovery" in
-behave-rfc3489bis) -- learn your public IP address and UDP port.   
To avoid

the problem Cullen described (where NATs seem to 'forget' to create
bindings) those binding discovery STUN packets to the STUN server 
(s) need to

be paced.

("Connectivity

ICE's connectivity checks don't need to be paced to be gentle for  
the same
reason, because ICE's connectivity checks don't create new NAT  
bindings
(pedantic readers know that there are some exceptional  
configurations where
ICE's connectivity checks do create a new NAT binding).  Rather,  
ICE's

rules into

   after we sent their request.  If we don't see the response in  
20ms,

2. Connectivity check:  connectivity checks don't occur until you  
know
   the peer's IP address and codecs.  That provides enough  
information
   about the expected bandwidth that ICE can stay below that  
bandwidth

3. NAT Keepavlies:  the initial RTT used by TCP SYNs seems reasonable
   (WinXP seems to wait 2 seconds, for whatever that's worth.   
RFC2988

-d

--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ  
07054-2711

Cisco Systems

---

From: Lars Eggert <[email-masked]>
Date: Wed, 6 Sep 2006 03:56:48 -0500 (CDT) (envelope-from [email-masked])

On Sep 6, 2006, at 1:09, Cullen Jennings wrote:

Actually, these issues were discussed and PWE3 will work on a common  
congestion control mechanism for their pseudowires, such that they  
can be used over best-effort networks. The current drafts say that  
people SHOULD really only run them over provisioned paths for that  
reason. Also, the deployment cases for pseudowires are different than  
for STUN/ICE, which I'd expect to run over much more diverse paths.

In any event, I'm confident that we can come up with a retransmission  
scheme that will support ICE and not be too aggressive. One idea is  
that a sender can detect when it has sent a spurious retransmission,  
because it will receive some sort of acknowledgment from the receiver  
for message it has already retransmitted. In such a case, it could  
back off the retransmission timer a bit. This would allow STUN to  
start with a short timer that would lengthen when used over long- 
delay paths.

Lars

Attachment:
smime.p7s

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Oct 2006 15:16:41 -0500 (CDT) (envelope-from [email-masked])

So, I went back and am re-reading various threads in RFC 3489bis as I 
work on the update, and this is a big one, and one that we did NOT resolve.

The question again is whether or not to change the 100ms initial 
retransmit interval for STUN. Dan had proposed to make the 
algorithms/defaults different for each usage. I had proposed it should 
not be different per usage, but that the hard part is in the choosing of 
the initial value. Cullen proposed that we shouldn't muck with what we 
did in rfc3489 without really good reason, and Lars is (I think) 
advocating something better than what is in 3489bis today.

To be clear, the big issue is that with ICE, the stun connectivity 
checks will almost always be to a host that is 'new' and for which a 
cached RTT estimate doesn't exist. Consequently, the checks will almost 
always use the default RTT. This is somewhat different than classic stun 
to a stun server (or the sip outbound usage) where you can do an RTT 
estimate.

I do think, as others do, that the 3s retransmit timer for TCP is 
entirely too long for ICE for an initial RTT estimate. The metric to use 
here is that this directly impacts call setup. If you want ICE to have a 
chance to pick the optimal path even if it saw a packet loss, you need 
to wait this initial retransmit interval at least as an additional call 
setup time. I'd argue its probably a few times this to really give it a 
chance. If we use say 4x, thats 12s which is way too long for call setup.

A more reasonable number is like 500ms-1000ms, and dividing by 4, well 
that gets us right back to around 125 to 250ms as the initial RTT estimate.

So, I would be OK with a change which keeps the current number at 100ms, 
allows it to be configurable and gives guidance on doing so for wireless 
clients, and then uses a cached RTT if there is one, along with the 
standard TCP formulas for backoff.

Thoughts?

-Jonathan R.

Lars Eggert wrote:

Actually, these issues were discussed and PWE3 will work on a common  
congestion control mechanism for their pseudowires, such that they  can 
be used over best-effort networks. The current drafts say that  people 
SHOULD really only run them over provisioned paths for that  reason. 
Also, the deployment cases for pseudowires are different than  for 
STUN/ICE, which I'd expect to run over much more diverse paths.

In any event, I'm confident that we can come up with a retransmission  
scheme that will support ICE and not be too aggressive. One idea is  
that a sender can detect when it has sent a spurious retransmission,  
because it will receive some sort of acknowledgment from the receiver  
for message it has already retransmitted. In such a case, it could  back 
off the retransmission timer a bit. This would allow STUN to  start with 
a short timer that would lengthen when used over long- delay paths.

Lars

------------------------------------------------------------------------

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 16 Oct 2006 16:38:19 -0500 (CDT) (envelope-from [email-masked])

...
> So, I would be OK with a change which keeps the current 
> number at 100ms, allows it to be configurable and gives 
> guidance on doing so for wireless clients,

Such guidance is helpful for the wireless client itself but
its peer (which may be on a wired network) doesn't know the
characteristics of that wireless technology (whatever those
characteristics might be -- slow?  lossy?).

> and then uses 
> a cached RTT if there is one, along with the standard TCP 
> formulas for backoff.
> 
> Thoughts?

That should work.  I expect you'll only allow an RTT to be 
cached for ~5 minutes, or until the connection is torn down,
whichever occurs first?

-d

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Oct 2006 17:15:57 -0500 (CDT) (envelope-from [email-masked])

inline.

Dan Wing wrote:

...

Since its a two-way handshake it may not really matter. The server side 
doesn't have to maintain a timer at all in fact. That said, Bruce has 
suggested in his comments that we are encountering requests that are not 
idempotent, such as TURN Allocate, and this means we DO need to have 
timers at the server for detecting idempotent requests, to resend the 
same response.

So, there are two responses to that. Firstly, I actually need to think 
more about whether TURN really is or isn't idempotent. A redone Allocate 
request will probably just extend the existing binding lifetime rather 
than creating a new one, which is exactly what you want. If it turns out 
its not idempotent, then we could just impost a large server timer that 
holds onto the resposne to resend, say 20s. I'm hoping that TURN is 
idempotent however. Back soon on that one...

and then uses 

Thoughts?

whichever occurs first?

Hmm, not sure. Are there established norms for this? For sip-outbound 
you'll keep the cache fresh for a long time. However for binding 
discovery unless you make calls every 5min you'll lose the cached RTT to 
your default server. It would be nice if you could cache it much longer. 
 I just don't know how long it is reasonable to assume its accurate.

-Jonathan R.