Subject: Re: [Ietf-behave] [Sip] Outbound - a new STUN keealive proposal

From: "Dan Wing" <[email-masked]>
Date: Tue, 15 Aug 2006 19:16:39 -0500 (CDT) (envelope-from [email-masked])

> >> 1. Editorial: Shouldn't the
> >>    stop-sending-STUN-requests-if-retransmissions-fail text (point
> >>    2) be in 3849bis?  To me it sounds like generic STUN
> >>    transaction procedures, which should be defined in the STUN
> >>    spec.  Or, do we consider it specific to the STUN keepalive
> >>    usage for SIP???
> >
> >Propose some text - as much as the advice can be made generic, I
> >would want it to be in 3849bis.  I suspect it hard to say too much
> >more than what is in 3849.
>
> I need to think a little more about this a little bit more.
>
> Chapter 7.1 of 3849bis does talk about STUN re-transimission timers,
> and when a transaction shall be considered to have failed.  But,
> there is no text about what happens after that.  THAT may be STUN
> usage dependent, though, and in some cases it could even be "an
> implementation issue"...
>
> But, I don't see anything SIP specific in saying that STUN
> keep-alive re-transmissions shall stop if there is no reply, so
> shouldn't that text be in 3849bis - either in the generic
> transaction chapter (chapter 7), or in the keep-alive usage chapter
> (12.4)? The part of the outbound spec defining the SIP usage of STUN
> keep-alive can then of course refer to that text in 3849bis.

It would be more appropriate in the keepalive usage section.

> My main concern is that we dont specify things which people will
> later find out belongs to another spec, and another WG.

My concern is that if you stop doing STUN keepalives because you 
haven't received a response in NNNN retransmissions, your NAT 
binding will time out soon thereafter.  So here is some proposed text 
for the RFC3489bis keepalive section:

  If, after retransmitting the STUN Binding Request NNNN times,
  the STUN client does not receive a STUN Binding Response, the
  STUN client should assume the STUN server is no longer 
  available.  The STUN client SHOULD cease retransmitting the
  STUN keepalives and inform other applications that the NAT
  binding is no longer valid (e.g., attempt to re-register if
  using SIP).

-d

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 16 Aug 2006 01:55:14 -0500 (CDT) (envelope-from [email-masked])

Hi Rohan,

We could write something like:

"If the STUN binding transaction fails, as described in 3489, the SIP UA
must/may/could/must not do this-and-that-SIP-procedure".

I have nothing against putting SIP specific actions into the outbound
draft, but anything that can be considered to be generic to STUN
keepalive usage should be in 3489bis.

Regards,

Christer 

-----Original Message-----
From: Rohan Mahy [mailto:rohan@xxxxxxxxxx] 
Sent: 16. elokuuta 2006 3:21
To: Dan Wing
Cc: Christer Holmberg (JO/LMF); 'Cullen Jennings'; 'SIP'; 'Rohan Mahy';
ietf-behave@xxxxxxxxxxxxxxxxxxx
Subject: RE: [Sip] Outbound - a new STUN keealive proposal

Hi,

I think this is a slippery slope for 3489bis.  I can think of about 3
use cases that would break, or at least would be confusing, with this
wording.
 I would like some time to propose language specific to SIP and STUN on
the same port that is appropriate.

thanks,
-rohan

>> But, I don't see anything SIP specific in saying that STUN keep-alive

>> re-transmissions shall stop if there is no reply, so shouldn't that 
>> text be in 3849bis - either in the generic transaction chapter 
>> (chapter 7), or in the keep-alive usage chapter (12.4)? The part of 
>> the outbound spec defining the SIP usage of STUN keep-alive can then 
>> of course refer to that text in 3849bis.
>
> haven't received a response in NNNN retransmissions, your NAT binding 
> will time out soon thereafter.  So here is some proposed text for the 
> RFC3489bis keepalive section:
>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 16 Aug 2006 01:56:15 -0500 (CDT) (envelope-from [email-masked])

Hi, 

>>and when a transaction shall be considered to have failed.  But, there

>>is no text about what happens after that.  THAT may be STUN usage 
>>dependent, though, and in some cases it could even be "an 
>>implementation issue"...
>>
>>My main concern is that we dont specify things which people will later

>>find out belongs to another spec, and another WG.
>
haven't received a response in NNNN retransmissions, 
>your NAT binding will time out soon thereafter.  So here is some
>  binding is no longer valid (e.g., attempt to re-register if

I don't think we need to talk about NNNN times. Can't we simply say "If
the STUN client does not receive a response, and the STUN transaction
fails, the STUN client should assume....".

Then, IF we want to talk about SIP actions taken due to the failure
(re-registers etc), THAT belongs to a SIP specific spec I think.

Regards,

Christer

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 15 Aug 2006 19:20:44 -0500 (CDT) (envelope-from [email-masked])

Hi,

I think this is a slippery slope for 3489bis.  I can think of about 3 use
cases that would break, or at least would be confusing, with this wording.
 I would like some time to propose language specific to SIP and STUN on
the same port that is appropriate.

thanks,
-rohan

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 16 Aug 2006 10:42:38 -0500 (CDT) (envelope-from [email-masked])

Christer, it is not that simple.  Does the STUN client send 
retransmissions?  What if the STUN transaction failed but other traffic 
to the same port succeeded before-hand?  afterwards?  What happens if 
the STUN transaction fails over an still open TCP connection?  What if 
your TCP connection stalls?

thanks,
-rohan

On Aug 15, 2006, at 23:55, Christer Holmberg ((JO/LMF)) wrote:

Hi,

there

later

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 17 Aug 2006 07:15:18 -0500 (CDT) (envelope-from [email-masked])

>Christer, it is not that simple.  Does the STUN client send
retransmissions? 

According to 3849bis, it does.

>What if the STUN transaction failed but other traffic to the same port
succeeded before-hand?  afterwards?

That is an interesting question. But, I don't tink it's SIP specific,
because that "other traffic" could be non-SIP.

But, I am not sure we want to specify behavior, saying that one protocol
behavior is dependent on another...

>What happens if the STUN transaction fails over an still open TCP
connection?  What if your TCP connection stalls?

That is also an interesting question. But, I don't think that is SIP
specific either.

So, there may be more issues we need to consider. But, if we can agree
they belong to 3849bis we can move the discussion to BEHAVE, and it
won't affect the work on the outbound spec.

But, again, if we want the STUN failure to trigger SIP specific actions
(e.g. trigger the sending of a new REGISTER), that should of course be
described in the outbound draft.

Regards,

Christer

>>  If, after retransmitting the STUN Binding Request NNNN times,  the 
>> STUN client does not receive a STUN Binding Response, the  STUN 
>> client should assume the STUN server is no longer  available.  The 
>> STUN client SHOULD cease retransmitting the  STUN keepalives and 
>> inform other applications that the NAT  binding is no longer valid 
>> (e.g., attempt to re-register if  using SIP).
>
> I don't think we need to talk about NNNN times. Can't we simply say 
> "If the STUN client does not receive a response, and the STUN 
> transaction fails, the STUN client should assume....".
>