Subject: [ippm] RE: TWAMP protocol

From: "Hedayat, Kaynam" <[email-masked]>
Date: Fri, 28 Sep 2007 17:55:16 -0400

Jeff,

Thank you for your comments. See reply below.

Regards,
Kaynam & Al 

> -----Original Message-----
> From: Jeff W. Boote [mailto:[email-masked]] 
> Sent: Monday, August 06, 2007 6:35 PM
> To: Hedayat, Kaynam
> Cc: Matthew J Zekauskas; IETF IPPM WG
> Subject: TWAMP protocol
> 
> I have a couple of high-level questions/suggestions for this protocol.
> 
> (I'm sorry I have not looked at this until now - I realize 
> this could be pretty late in the process and I understand 
> these suggestions could get the same amount of attention I 
> have given twamp up till now. ;) )
> 
> 1) Why not use the extension mechanism built into OWAMP to 
> indicate the additional/different functionality? (The 'Modes' 
> word of the server greeting.)
> 
> Currently, there is no way for a twamp or owamp client to 
> determine the difference between an owamp and twamp server 
> until it actually requests a test. 
> This is after the authentication phase. If this protocol is 
> going to piggy-back on the same port number, I think it 
> should be a more cooperative citizen.
> 
> The owamp protocol allowed for an extension mechanism, I 
> think it should be used for this. I think it would also make 
> the additional IANA registry unneeded. (An errata to the 
> owamp spec would be good to include the additional mode bits used.)
Although this is a good idea please note that we still need the IANA
Registry since the TWAMP Request-Session is a new message that is
different than the OWAMP Request-Session message. Your suggestion does
move up the control of the mode selection higher up in the protocol.
However, at this stage and with the amount of changes it introduces in
the protocol we feel that the current mechanism meets the needs of the
protocol.
> 
> 2) I'm a bit concerned with the fact that the request-session 
> does not indicate anything about the schedule at all. 
> Minimally, as someone running a server, I would want a way to 
> indicate how much traffic I was willing to accept. There does 
> not seem to be any way for the server to decide how intensive 
> of a test to allow. If nothing else, the schedule could be 
> used to indicate a MAX rate that the client promises not to 
> exceed. (Obviously, it could lie and attempt to use more. 
> But, it would also be possible for the reflector to report 
> the abuse and shut down that socket.)
TWAMP servers are meant to be implemented with low overhead on the
server (simply reflecting packets). The schedule made more sense in the
OWAMP case since the server processes the packets. That said, in TWAMP
the servers can certainly reject new sessions if they are over-burdened.

> jeff

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

---

From: "Jeff W. Boote" <[email-masked]>
Date: Fri, 28 Sep 2007 16:57:09 -0600

> the protocol we feel that the current mechanism meets the needs of the

First, this does not address the point of how a twamp or owamp client would 
differentiate between these servers. These are fundamentally different tests, 
and I'm concerned with idea of having twamp clients attempting to run tests 
against existing owamp servers. There doesn't seem to be any mechanism to 
determine if the server is an owamp or twamp server, other than attempting to 
use this new message. An owamp server, not knowing anything about this message 
should just close the socket. That is not really a clear indication of the 
problem to the client.

Second, I am curious what more you think would change in the protocol other than 
one bit of the mode word?

Third, the reason I said the IANA registry would be unneeded, is that a 
different mode bit could just as easily indicate a completely different set of 
messages. I was referring to an IANA registry for the OWAMP-Control commands. It 
probably would still be useful to use an IANA registry to keep track of 
individual mode bits. The mode bits would represent the full set of protocol 
messages that are allowed for that given protocol mode.

> the servers can certainly reject new sessions if they are over-burdened.

It is of course possible for the server to deny new sessions if it is 
over-burdened. But, if you don't know how much traffic each session is likely to 
produce, how many should it accept? And what should a server do if several 
sessions begin to ramp up after they have been accepted? Presumably a server 
could kill existing sessions to reduce the load. However, I think it will be 
very difficult for clients to determine 'why' the sessions have started failing 
in that case. A limited amount of 'reservation' in the system allows much better 
predictability.

This issue is not really that big of a deal to me. But, I can tell you based on 
owamp deployments, that users almost always want to limit the intensity of test 
traffic somehow. And that they are probably more likely to install twamp servers 
if there are available controls.

The first issue is more important to me because I think this could adversely 
effect existing OWAMP servers and clients.

jeff

---

From: Al Morton <[email-masked]>
Date: Sat, 29 Sep 2007 10:11:55 -0400

Jeff,

Please see some additional thoughts and replies below.

Al

At 06:57 PM 9/28/2007, Jeff W. Boote wrote:
>>>indicate the additional/different functionality? (The 'Modes' word 
>>>of the server greeting.)
>>>
>>>determine the difference between an owamp and twamp server until 
>>>it actually requests a test. This is after the authentication 
>>>phase. If this protocol is going to piggy-back on the same port 
>>>number, I think it should be a more cooperative citizen.
>>>
>>>The owamp protocol allowed for an extension mechanism, I think it 
>>>should be used for this. I think it would also make the additional 
>>>IANA registry unneeded. (An errata to the owamp spec would be good 
>>>to include the additional mode bits used.)

Jeff wrote:
>First, this does not address the point of how a twamp or owamp 
>client would differentiate between these servers. These are 
>fundamentally different tests, and I'm concerned with idea of having 
>twamp clients attempting to run tests against existing owamp 
>servers. There doesn't seem to be any mechanism to determine if the 
>server is an owamp or twamp server, other than attempting to use 
>this new message. An owamp server, not knowing anything about this 
>message should just close the socket. That is not really a clear 
>indication of the problem to the client.

Why wouldn't the OWAMP-only Server respond with a non-zero Accept field
in the Accept-Session message?  This would provide a clear indication,
and then the Server is prohibited from simply closing the connection.

OWAMP says:
...
>3.3.  Values of the Accept Field
>    Accept values are used throughout the OWAMP-Control protocol to
>    communicate the server response to client requests.  The full set of
>    valid Accept field values are as follows:
>      0    OK.
>      1    Failure, reason unspecified (catch-all).
>      2    Internal error.
>      3    Some aspect of request is not supported.
...
Values 1 or 3 seem applicable here. Also, in section 3.5 on the
Accept Session Message:
...
>    In this message, zero in the Accept field means that the server is
>    willing to conduct the session.  A non-zero value indicates rejection
>    of the request.  The full list of available Accept values is
>    described in Section 3.3, "Values of the Accept Field".
>
>    If the server rejects a Request-Session message, it SHOULD not close
>    the TCP connection.  The client MAY close it if it receives a
>    negative response to the Request-Session message.
...

The expectation of Accept field usage seems like a reasonable
interpretation of the OWAMP spec, to me.
(unless there's an OWAMP paragraph that says
"close the socket if an unexpected command is received"
which wouldn't be very tuned-in to Postel's robustness principle
http://tools.ietf.org/html/rfc793#section-2.10 ).

Jeff wrote:
>Second, I am curious what more you think would change in the 
>protocol other than one bit of the mode word?

I think the point is that this is *another change*, and the mantra
has been to minimize changes to OWAMP when developing TWAMP.

Jeff wrote:
>Third, the reason I said the IANA registry would be unneeded, is 
>that a different mode bit could just as easily indicate a completely 
>different set of messages. I was referring to an IANA registry for 
>the OWAMP-Control commands. It probably would still be useful to use 
>an IANA registry to keep track of individual mode bits. The mode 
>bits would represent the full set of protocol messages that are 
>allowed for that given protocol mode.

Right, yet another IANA registry would be needed to keep track of
extensions to the mode bits. Kaynam and I concluded that the
new Session Request command, with no schedule and other changes,
would still require an IANA registry, so we propose to create only
one at this time. Having the "mode" change a command so drastically
didn't seem clear.

Another view:  we are envisioning *many* Server/Session-Reflectors
that support TWAMP at a minimum, and perhaps a subset that support both.
OWAMP-only clients have a simple way out of a session they can't support
by using the Accept field.