Subject: [xmpp] #23: to error or not when handling an idle stream

From: "xmpp issue tracker" <[email-masked]>
Date: Mon, 14 Jun 2010 20:56:11 -0000

#23: to error or not when handling an idle stream
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |       Owner:  stpeter@…         
     Type:  defect              |      Status:  new               
 Priority:  minor               |   Milestone:                    
Component:  3920bis             |     Version:                    
 Severity:  In WG Last Call     |    Keywords:                    
--------------------------------+-------------------------------------------
 Regarding Section 4.3.3 (Handling of Idle Stream), Dave Cridland
 commented:

 "an idle stream can, surely, be closed with a stream error of connection-
 timeout - §4.6.3.4 seems to describe this case. I don't follow why this is
 MUST NOT (here) and RECOMMENDED against (4.6.3.4) - these conflict in any
 case. Surely a client session, in particular, being disconnected due to
 non-response should be given a stream error?"

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/xmpp/trac/ticket/23>
xmpp <http://tools.ietf.org/xmpp/>

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 27 Jun 2010 18:16:28 -0600

> #23: to error or not when handling an idle stream

I agree that we want to make a consistent recommendation here.

At one point Philipp Hancke convinced me that it's a bad idea to return
a stream error simply because a client hasn't sent any data in awhile.
Given the existence of whitespace keepalives and XMPP pings (XEP-0199)
and stream management (XEP-0198), it seems that we have ways of making
sure that a client receiving a <connection-timeout/> stream error truly
has timed out the connection. Therefore I'd be willing to modify the
current text and harmonize the recommendation to say that a server is
justified in sending a <connection-timeout/> stream error if the client
(or peer server) is not responsive.

I'll let Philipp make his case for the less strict approach.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "xmpp issue tracker" <[email-masked]>
Date: Mon, 28 Jun 2010 01:58:18 -0000

#23: to error or not when handling an idle stream
--------------------------------+-------------------------------------------
 Reporter:  stpeter@…           |        Owner:  stpeter@…         
     Type:  defect              |       Status:  closed            
 Priority:  minor               |    Milestone:                    
Component:  3920bis             |      Version:                    
 Severity:  In WG Last Call     |   Resolution:  fixed             
 Keywords:                      |  
--------------------------------+-------------------------------------------
Changes (by stpeter@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Provisionally resolved as follows:

 1. In Section 4.6.3.4, changed definition of <connection-timeout/> error
 to the following (focusing on lack of response, not lack of sending):

    A connected client or peer server has not responded to stanzas or
    other data (e.g., whitespace keepalives as described under
    Section 4.3.3) for some configurable period of time and therefore the
    stream is being closed.

 2. In Section 4.3, removed this text:

    Implementation Note: As described under Section 4.3.3, an idle
    stream SHOULD NOT be considered a trigger for a stream error.

 3. In Section 4.3.3, removed this text:

    To close an idle stream with a local client or remote server, a
    server MUST close the stream without error as explained under
    Section 4.3.2.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/xmpp/trac/ticket/23#comment:1>
xmpp <http://tools.ietf.org/xmpp/>

---

From: Philipp Hancke <[email-masked]>
Date: Mon, 28 Jun 2010 09:29:19 +0200

> a stream error simply because a client hasn't sent any data in awhile.

Yes. That mostly applies to s2s behaviour where as stream is closed when 
no stanza has been received for a certain amount of time. And that is 
still true.

> has timed out the connection. Therefore I'd be willing to modify the

Will a client that does not respond to pings send TCP level acks?

> (or peer server) is not responsive.

+1, this definition of makes sense.

In 4.3.3. could you move the last sentence to the front? Currently, it 
looks too much like you must close an idle TCP connection without stream 
error.

An XML stream can become idle, i.e., neither entity has sent XMPP 
traffic over the stream for some period of time. To close such an idle 
stream with a local client or remote server, a server MUST close the 
stream without error as explained under Section 4.3.2. The idle timeout 
period ...

And in 4.6.3.4 (after redefining the stream error):

Note: In RFC 3920, this stream error was used if the peer has not 
generated any traffic over the stream for some period of time. This is 
not recommended as explained under Section 4.3.3.

cheers

philipp

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 28 Jun 2010 08:53:47 -0600

> not recommended as explained under Section 4.3.3.

Those sections have changed based on rewrites as described in other
threads. I'll paste the text that's currently in my working copy so that
you can review it and comment on the list:

###

4.3.  Closing a Stream

4.3.1.  Process

   An XML stream between two entities can be closed at any time, either
   because a specific stream error has occurred or in the absence of an
   error (e.g., when a client simply ends its session).

   A stream is closed by sending a closing </stream> tag.

   S: </stream:stream>

   The entity that sends the closing stream tag SHOULD behave as
   follows:

   1.  Wait for the other party to also close its stream before
       terminating the underlying TCP connection (this gives the other
       party an opportunity to finish transmitting any data in the
       opposite direction before the TCP connection is terminated).

   2.  Refrain from initiating the sending of further data over that
       stream but continue to process data sent by the other entity
       (and, if necessary, react to such data).

   3.  Consider both streams to be void if the other party does not send
       its closing stream tag within a reasonable amount of time (where
       the definition of "reasonable" is a matter of implementation or
       deployment).

   4.  After receiving a reciprocal closing stream tag from the other
       party or waiting a reasonable amount of time with no response,
       MUST terminate the underlying TCP connection or connections.

4.3.2.  Handling of Idle Streams

   An XML stream can become idle when neither entity has sent XMPP
   traffic over the stream for some period of time.  There are many
   reasons why a stream might be, or appear to be, idle (e.g., simple
   inactivity or a lost network connection at a level below XMPP).

   One common method for preventing a stream from going idle is to send
   a space character (U+0020) between XML stanzas, which is allowed for
   XML streams as described under Section 11.7; the sending of such a
   space character is properly called a WHITESPACE KEEPALIVE (the term
   "whitespace ping" is often used, despite the fact that it is not a
   ping since no "pong" is possible).  Other connection-testing methods
   include the application-level pings described in [XEP-0199] and the
   more comprehensive stream management protocol described in
   [XEP-0198].

   Implementers are advised to support whichever connection-testing
   methods they deem appropriate, but to carefully weigh the network
   impact of such methods against the benefits of discovering idle
   streams in a timely manner.  The length of time between the use of
   any particular connection test is very much a matter of local service
   policy and depends strongly on the network environment and usage
   scenarios of a given deployment and connection type; at the time of
   writing, it is RECOMMENDED that any such test be performed not more
   than once every 5 minutes and that, ideally, such checks will be
   initiated by clients rather than servers.  Those who implement XMPP
   software and deploy XMPP services are encouraged to seek additional
   advice regarding appropriate timing of stream-level keepalives,
   particularly when power-constrained devices are used (e.g., in mobile
   environments).

   In the absence of such methods, an entity MAY time out the stream
   after some period of time.  The timeout period is a matter of
   implementation and local service policy; however, it is RECOMMENDED
   to be liberal in accepting idle streams, since experience has shown
   that doing so improves the reliability of communication over XMPP
   networks.  In particular, it is typically more efficient to maintain
   a stream between two servers than it is to aggressively timeout such
   a stream, especially with regard to synchronization of presence
   information as described in [XMPP-IM]; therefore it is RECOMMENDED to
   maintain such a stream since experience has shown that server-to-
   server streams are cyclical and typically need to be re-established
   fairly frequently (e.g. at least every 24 hours) if they are timed
   out.

###

4.6.3.4.  connection-timeout

   A connected client or peer server has not responded to stanzas or
   other data (e.g., whitespace keepalives as described under
   Section 4.3.2) for some configurable period of time and therefore the
   stream is being closed.

   P: <stream:error>
        <connection-timeout
            xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
      </stream:error>
      </stream:stream>

###

I'm still not quite sure that we've properly defined "idle stream" or
that we've properly differentiated between "not sending data over the
stream" and "not responding to data received over the stream", so
feedback is welcome. I do agree that we need an implementation note or
interoperability note in Section 4.6.3.4 about the fact that the
<connection-timeout/> error is properly about not responding to data,
whereas in RFC 3920 it was defined as not sending data:

   o  <connection-timeout/> -- the entity has not generated any traffic
      over the stream for some period of time (configurable according to
      a local service policy).

So your proposed text seems good, tweaks as follows:

   Interoperability Note: RFC 3920 specified that this stream error
   is to be used if the peer has not generated any traffic over the
   stream for some period of time. That behavior is no longer
   recommended.

/psa

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 28 Jun 2010 08:57:15 -0600

On 6/28/10 8:53 AM, Peter Saint-Andre wrote:

> I do agree that we need an implementation note or

Further tweaked as follows:

      Interoperability Note: RFC 3920 specified that the <connection-
      timeout/> stream error is to be used if the peer has not generated
      any traffic over the stream for some period of time.  That
      behavior is no longer recommended; instead, the error SHOULD be
      used only if the connected client or peer server has not responded
      to data sent over the stream.

/psa

---

From: Matthew Wild <[email-masked]>
Date: Mon, 28 Jun 2010 19:00:30 +0100

>   fairly frequently (e.g. at least every 24 hours) if they are timed

This text seems fairly sensible to me, though I have some notes below.

>   Section 4.3.2) for some configurable period of time and therefore the

This part reads as if you can "respond" to whitespace keepalives,
which I don't think is right.

> feedback is welcome.

There's nothing really wrong with an "idle stream" (which sounds like
a perfectly normal thing to me), so we don't want the text to sound
like closing them is something everyone should be doing. "Not sending
data over the stream" sits with this too.

"Not responding to data received over the stream" is likely more up to
implementation/deployment for specifics, but the key point here is
that connection-timeout is to be used for when a party believes (via
one means or another, e.g. detected silence, unanswered pings, stream
management) that its peer has stopped talking for good.

Regards,
Matthew

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 28 Jun 2010 13:12:06 -0600

> which I don't think is right.

Good point.

> management) that its peer has stopped talking for good.

More good points. So:

   One party is closing the stream because it has reason to believe that
   the other party has permanently lost the ability to communicate over
   the stream.  The lack of ability to communicate can be discovered
   using various methods, such as whitespace keepalives as specified
   under Section 4.3.2, XMPP-level pings as defined in [XEP-0199], and
   XMPP stream management as defined in [XEP-0198].

---

From: Matthew Wild <[email-masked]>
Date: Mon, 28 Jun 2010 20:20:55 +0100

>   XMPP stream management as defined in [XEP-0198].

+1 :)

Matthew