Subject: Re: [ippm] Question on starting test streams

From: "Jeff W. Boote" <[email-masked]>
Date: Thu, 03 Jan 2008 14:06:03 -0700

Murtaza Chiba wrote:
> Hello,
>    The RFC 4656 is not quite clear on how the Test streams are 
> instantiated.   It just mentions that upon sending the Start-Ack the 
> Server should start the streams, however, the Server is not the 
> Session-Sender and hence I am not sure if a control packet exists to set 
> that up.

In section 3.7 (Starting Test Sessions), it actually states:

    The server SHOULD start all OWAMP-Test streams immediately after it
    sends the response or immediately after their specified start times,
    whichever is later.  If the client represents a Sender, the client
    SHOULD start its OWAMP-Test streams immediately after it sees the
    Start-Ack response from the Server (if the Start-Sessions command was
    accepted) or immediately after their specified start times, whichever
    is later.  See more on OWAMP-Test sender behavior in a separate
    section below.

The test stream here can be send or receiver. The only OWAMP control messages to 
set that up is the Start-Sessions message, and the Start-Ack message. How the 
client communicates with the actual Session-Sender/Session-Receiver is outside 
of the scope of RFC 4656. (Likewise, how the server communicates with the actual 
Session-Sender/Session-Receiver.) These relationships are described in section 
1.2 of the document and are represented by the unlabeled links in the figure.

(In the Internet2 implementation - this is done via pipes and unix signals since 
the session test processes are always on the same host as the control-client or 
server.)

>   From the block diagrams it seems that the Server does not 
> communicate directly with the Session-Sender.

That diagram is showing one possible relationship. Another possible relationship 
would be with the Session-Sender and Session-Receiver blocks swapped.

(An even more esoteric possibility would be if the server was connected to both 
the Session-Sender and Session-Receiver - this is valid in the protocol, though 
I know of no implementation that supports it.)

>   So is the information 
> transmitted by the Control-Client to the Session-Sender while the 
> Session-Receiver is informed by the Server?   If so how is any 
> communication lag adjusted between the two separate legs  (CC -> SS and 
> S -> SR) accounted for?

There are multiple lag time issues to account for in this protocol. A few ways 
these are managed:

1) Clients can request test periods that start in the future by enough time to 
deal with any lag. (For example, the Internet2 implementation estimates 
round-trip time in the initial control protocol and uses that to make a good 
guess as to how far in the future it should request tests to ensure both sides 
can be ready before the requested start time.)

2) Section 4 describes sender behavior for dealing with packet send schedules 
with times in the past. Specifically, senders skip the sending of any packets 
that should have been sent more than 'timeout' in the past. Upon termination of 
the test session, a record of all packets that were 'skipped' is sent to the 
receiver (in the Stop-Sessions message) so this information can be stored with 
the session data. This information is returned to the client in the 
Fetch-Session response, so missing packet records that actually represent 
packets that were never sent can be ignored.

3) One of the more tricky lag-time issues to deal with is discussed at length in 
the Stop-Sessions description in section 3.8. If sessions are terminated early, 
there are some data quality issues to deal with.

jeff

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

---

From: "Murtaza Chiba" <[email-masked]>
Date: Sat, 5 Jan 2008 16:08:51 +0400

Hello Jeff,
   Thanks for the detailed response that answers a lot of my questions.  It
seems that the communication with Test Endpoints and Server/Client has been
left open.   Just curious to know the reason behind that.

Thanks,
-Murtaza

---

From: "Jeff W. Boote" <[email-masked]>
Date: Sat, 05 Jan 2008 12:57:36 -0700

Murtaza Chiba wrote:
> Hello Jeff,
>    Thanks for the detailed response that answers a lot of my questions.  
> It seems that the communication with Test Endpoints and Server/Client 
> has been left open.   Just curious to know the reason behind that.

 From my perspective, there was no compelling reason to standardize that part of 
the communication. (And plenty of reasons not to - I strongly suspect we would 
have failed to reach consensus on that portion.)

For many valid implementations, that part of the communication is simply a 
function call or an IPC to another process or thread on the same host.

I have not thought that much about it, but I suspect for distributed 
implementations you could even use OWAMP-Control for that communication - and 
essentially create an OWAMP proxy...

jeff