Subject: RE: [ippm] TWAMP Remote Session-Sender Initiation

From: "Hedayat, Kaynam" <[email-masked]>
Date: Fri, 28 Sep 2007 18:05:28 -0400

Walt,
 
These are fine suggestions but out of the scope of the current TWAMP
draft. Al and I are interested to work on these ideas with you and
propose these extensions. Are you planning to attend the next IETF
meeting?
 
Regards,
Kaynam

________________________________

	From: WALT STEVERSON [mailto:[email-masked]] 
	Sent: Monday, August 06, 2007 11:43 PM
	To: [email-masked]
	Subject: [ippm] TWAMP Remote Session-Sender Initiation

	Would there be any interest in defining a way for a remote
client to request that a Session-Sender initiate a test session to a
Session-Reflector and then gather the results of that test?  Right now a
Control-Client can effectively negotiate the configuration and starting
of a Session-Reflector.  Why not allow a Control-Client to also
negotiate the configuration and starting of a Session-Sender?  Two (or
more) test endpoints could be placed in a network and a central agent
could open TWAMP-Control connections to both endpoints, configure one as
the Session-Sender, and the other as the Session-Reflector.  This might
involve modification to the TWAMP Request-TW-Session message behavior
(keying off the Conf-Sender/Conf-Receiver fields?) or maybe a completely
new message type.  When a test completes the central agent would
probably want to gather the results.  This might mean reinstating the
Fetch-Session and Fetch-Ack messages in the TWAMP-Control protocol so
that all the results that are collected by the Session-Sender could be
sent back to the central agent for further processing.  Of course that
would require the OWAMP Fetch-Ack message format to be extended to
include Sender Timestamp, Sender Error Estimate, and Sender Sequence
Number information in each packet record.
	
	Expanded Role Diagram:

	  +----------------+                +-------------------+
	  | Session-Sender |<--TWAMP-Test-->| Session-Reflector |
	  +----------------+                +-------------------+ 
	          ^                                  ^
	          |                                  |
	          |                                  | 
	          v                                  v
	  +----------------+                 +----------------+
	  | Control-Server |                 | Control-Server | 
	  +----------------+                 +----------------+
	        ^  ^                                    ^
	        |  |                                    |
	        |  |                                    |
	        |  +--TWAMP-Control--+  +-TWAMP-Control-+ 
	        |                    |  |
	        |                    |  |
	  TWAMP-Control              |  |
	        |                    |  |
	        |                    |  |
	        v                    v  v
	  +--------------+     +----------------+ 
	  | Fetch-Client |     | Control-Client |
	  +--------------+     +----------------+

	Collapsed Role Diagram:

	  +----------------+                +-------------------+
	  | Session-Sender |<--TWAMP-Test-->| Session-Reflector |
	  | Control-Server |                | Control-Server    |
	  +----------------+                +-------------------+ 
	          ^                                  ^
	          |                                  |
	          |                                  | 
	    TWAMP-Control                            |

	          |                                  |
	          |                                  |
	          |     +------ TWAMP-Control -------+
	          |     |
	          v     v
	  +----------------+

	  | Control-Client |
	  | Fetch-Client   |
	  +----------------+

	This behavior could be made purely optional if it used the
existing TWAMP Request-TW-Session message and any Control-Server that
did not support this functionality could just refuse the session in its
Accept-Session message (accept field == 3, "Some aspect of request is
not supported"). 

	The argument could be made that it is possible to setup an
equivalent remote bidirectional test with OWAMP using simultaneous
one-way test tests so why should TWAMP be expanded to do it too?  In the
abstract section of the TWAMP draft it says that OWAMP does not
accommodate round-trip or two-way measurements.  Also, the Reflector
could still be a TWAMP Light reflector and then the burden of
implementing TWAMP-Control protocol resides in the endpoint that serves
as the Session-Sender (see diagram below).

	TWAMP Light Diagram:

	  +----------------+                +-------------------+
	  | Session-Sender |<--TWAMP-Test-->| Session-Reflector |
	  | Control-Server |                |                   |
	  +----------------+                +-------------------+ 
	          ^                                   ^
	          |                                   |

	    TWAMP-Control                             |

	          |                                   |
	          |                                   |
	          |     +-----------------------------+
	          |     |
	          v     v
	  +----------------+

	  | Control-Client |
	  | Fetch-Client   |
	  +----------------+

	Something similar could also be accomplished with SNMP MIBs for
configuring TWAMP Session-Senders and for gathering the resulting test
measurements.  However, this is so similar to the existing OWAMP-Control
behavior (ie. Fetch-Session, Fetch-Ack, Request-Session) that, in my
opinion, it seems more natural to extend the TWAMP-Control protocol to
support this functionality.

	Regards,
	Walt Steverson

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