Subject: [ippm] AUTH48 [SG]: RFC 5357 <draft-ietf-ippm-twamp-09.txt>

From: Al Morton <[email-masked]>
Date: Tue, 16 Sep 2008 09:04:24 -0400

At 05:30 PM 9/12/2008, RFC Editor wrote:
>Al,
>
>We have corrected the text as requested and posted the revised version
>of the document at:
>
>    ftp://ftp.rfc-editor.org/in-notes/authors/rfc5357.txt
>...

IPPM WG,

In the final phase of TWAMP editing, we identified a case
that is important enough to fix now, with your agreement.

Adding a short phrase will solve a small issue with the
connection/session "liveliness" timeouts, SERVWAIT and REFWAIT.
These timeouts are not mandatory in the Server/Reflector.

If we can obtain WG consensus to fix this now, it would be a
good thing.

Please review this ASAP and reply to the list.

Background

The host acting as the responder has two "liveliness" timers:
SERVWAIT is for monitoring activity on the TWAMP-Control connection
(see par. 3 of section 3.1)
REFWAIT is for monitoring activity on each TWAMP-Test session
(see last par. of section 4.2)

     controller                              responder
+-----------------+                   +-------------------+
| Control-Client  |<--TWAMP-Control-->| Server  (SERVWAIT)|
|                 |                   |                  |
| Session-Sender  |<--TWAMP-Test----->| Session-Reflector |(REFWAIT)
+-----------------+                   +-------------------+

When we added these timers in the TWAMP memo, we
decided that the responder should suspend monitoring the
TWAMP-Control connection while any TWAMP-Test session is in
progress and the REFWAIT timer is in force. However, the transfer
back to monitoring the Control connection with the SERVWAIT timer
is not as straightforward as we thought.

The relevant sentence from section 3.1 is:

         ...The Server SHALL suspend monitoring control
       connection activity after receiving a Start-Sessions command, and
       SHALL resume after receiving a Stop-Sessions command (IF the
       SERVWAIT option is supported).  Note that the REFWAIT timeout
       (described below) covers failures during test sessions.

The issue occurs when there is a failure while test sessions are
in-progress and the Server in the responder never receives a
Stop-Sessions command. As a result, the Server leaves its
TWAMP-Control connection open because it does not resume
monitoring for connection liveliness with the SERVWAIT timer.
This is exactly what we were trying to avoid.

We think the simplest way to fix this is to add a phrase in
paragraph 3, section 3.1:

OLD
...The Server SHALL suspend monitoring control
connection activity after receiving a Start-Sessions command, and
SHALL resume after receiving a Stop-Sessions command (IF the
SERVWAIT option is supported).  Note that the REFWAIT timeout
(described below) covers failures during test sessions.

NEW
...The Server SHALL suspend monitoring control
connection activity after receiving a Start-Sessions command, and
SHALL resume after receiving a Stop-Sessions command (IF the
SERVWAIT option is supported).  Note that the REFWAIT timeout
(described below) covers failures during test sessions,
and if REFWAIT expires on ALL test sessions initiated by a
TWAMP-Control connection, then the SERVWAIT monitoring SHALL
resume (as though a Stop-Sessions command had been received).

(last 3 lines above are new)

Comments?

Al

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

---

From: "Murtaza Chiba (mchiba)" <[email-masked]>
Date: Tue, 16 Sep 2008 08:10:56 -0700

The proposed change sounds correct.

Thanks,
_murtaza  

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Al Morton
> Sent: Tuesday, September 16, 2008 6:04 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: [ippm] AUTH48 [SG]: RFC 5357 <draft-ietf-ippm-twamp-09.txt>
> 
> SERVWAIT is for monitoring activity on the TWAMP-Control 
> connection (see par. 3 of section 3.1) REFWAIT is for 
> monitoring activity on each TWAMP-Test session (see last par. 
> of section 4.2)
> 
>      controller                              responder
> When we added these timers in the TWAMP memo, we decided that 
> the responder should suspend monitoring the TWAMP-Control 
> connection while any TWAMP-Test session is in progress and 
> the REFWAIT timer is in force. However, the transfer back to 
> monitoring the Control connection with the SERVWAIT timer is 
> not as straightforward as we thought.
> 
> The issue occurs when there is a failure while test sessions 
> are in-progress and the Server in the responder never 
> receives a Stop-Sessions command. As a result, the Server 
> leaves its TWAMP-Control connection open because it does not 
> resume monitoring for connection liveliness with the SERVWAIT timer.
> ...The Server SHALL suspend monitoring control connection 
> activity after receiving a Start-Sessions command, and SHALL 
> resume after receiving a Stop-Sessions command (IF the 
> ...The Server SHALL suspend monitoring control connection 
> activity after receiving a Start-Sessions command, and SHALL 
> resume after receiving a Stop-Sessions command (IF the 
> (described below) covers failures during test sessions, and 
> if REFWAIT expires on ALL test sessions initiated by a

---

From: Al Morton <[email-masked]>
Date: Wed, 24 Sep 2008 08:20:05 -0400

Henk and all,

Apparently, this thread from last week was never posted
to the list (see below).

Emile simply points out that an implementation of SERVWAIT
should also implement REFWAIT to work as recommended.
There's another sentence to add (below) to accomplish this.

NEW
An implementation which supports the SERVWAIT timeout
SHOULD also implement the REFWAIT timeout.

(now, last 5 lines above are new)

I think that does it,
Al

At 07:41 AM 9/17/2008, Al Morton wrote:
>Because I didn't look at the addresses carefully,
>I thought this exchange *already* included IPPM.
>
>Feel free to send the entire thread to the list
>(indicating your opinion).
>
>thanks,
>Al
>
>At 03:26 AM 9/17/2008, [email-masked] wrote:
>>Hi Al
>>
>>Exactly, TWAMP-Control and TWAMP-test must work 
>>consistently when this option is selected.
>>
>>Does it help to push it to the ML?
>>
>>Regards
>>Emile
>>
>> > -----Message d'origine-----
>> > De : Al Morton [mailto:[email-masked]]
>> > Envoyé : mardi 16 septembre 2008 15:56
>> > À : STEPHAN Emile RD-CORE-LAN
>> > Objet : RE: [ippm] AUTH48 [SG]: RFC 5357 <draft-ietf-ippm-twamp-09.txt>
>> >
>> > Emile,
>> >
>> > Changing that MAY to a MUST would mandate the REFWAIT timer,
>> > which we're not seeking to do.
>> >
>> > If you are saying that:
>> > An implementation which supports the SERVWAIT timeout option
>> > SHOULD also implement the REFWAIT timeout option.
>> >
>> > I think that's reasonable to add.
>> >
>> > Al
>> >
>> > At 09:36 AM 9/16/2008, [email-masked] wrote:
>> > >...
>> > > From my understanding we have to change the following too:
>> > >
>> > >Old:
>> > >"The Session-Reflector MAY
>> > >    discontinue any session that has been started when no packet
>> > >    associated with that session has been received for REFWAIT seconds."
>> > >
>> > >New:
>> > >"The Session-Reflector MUST
>> > >    discontinue any session that has been started when no packet
>> > >    associated with that session has been received for REFWAIT seconds."
>> > >
>> > >Regards
>> > >emile
>> > >
>> > >
>> > > > -----Message d'origine-----
>> > > > De : [email-masked] [mailto:[email-masked]] De la part
>> > de Al
>> > > > Morton
>> > > > Envoyé : mardi 16 septembre 2008 15:04
>> > > > À : [email-masked]
>> > > > Cc : [email-masked]; [email-masked]
>> > > > Objet : [ippm] AUTH48 [SG]: RFC 5357 <draft-ietf-ippm-twamp-09.txt>
>> > > >

---

From: Henk Uijterwaal <[email-masked]>
Date: Wed, 24 Sep 2008 15:06:31 +0200

Hi Al,

> Apparently, this thread from last week was never posted

No, I didn't see this.  Let's have another week for comments :-)

Henk

>>> Exactly, TWAMP-Control and TWAMP-test must work consistently when 
>>> this option is selected.
>>>
>>> connection
>>> > > >        connection activity after receiving a Start-Sessions 
>>> command,
>>> > and

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

Ceterum censeo Asplain esse delendam  (Cato & Henk)
_______________________________________________
ippm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ippm

---

From: Henk Uijterwaal <[email-masked]>
Date: Wed, 01 Oct 2008 08:32:46 +0200

Al, others,

> No, I didn't see this.  Let's have another week for comments :-)

There were no further comments on this, so please make the changes and let's
finish this document.

Henk