Re: [ippm] Re: TWAMP protocol

["Jeff W. Boote" <boote at internet2.edu>]

Al Morton wrote:
> 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:

The Accept values are used in very specific locations in the OWAMP protocol. 
They are not a response to random data. A TWAMP client would be sending a bit 
pattern that is not recognized by an OWAMP server. To an OWAMP server, this 
would indicate a non-functional or errant client.

The point is the first 8 bits of control messages were NOT identified in the 
OWAMP protocol as an extensible field. If there is anything there other than the 
very specific things an implementation expects, it is an error condition.

It would of course be possible to issue an errata to the OWAMP protocol, but it 
would be far more extensive than pointing at an IANA registry of Control-Message 
identifiers. You would have to cull-out that field as something unique and 
indicate how it needs to be extensible.

I for one would not be in favor of this since it adversely effects existing 
clients and servers, and there is a reasonable work-around in using the OWAMP 
defined extension mechanism.

> ...
> >    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.

The suggestion I have given means 0 changes for the OWAMP protocol. The mode 
field was called out in RFC 4656 to make this extensible:

   The following Mode values are meaningful: 1 for unauthenticated, 2
   for authenticated, and 4 for encrypted.  The value of the Modes field
   sent by the server is the bit-wise OR of the mode values that it is
   willing to support during this session.  Thus, the last three bits of
   the Modes 32-bit value are used.  The first 29 bits MUST be zero.  A
   client MUST ignore the values in the first 29 bits of the Modes
   value.  (This way, the bits are available for future protocol
   extensions.  This is the only intended extension mechanism.)

OWAMP clients already MUST ignore those bits. This makes it very simple for a 
TWAMP client to use them without it effecting OWAMP at all.

OWAMP servers could, if they wanted - support the TWAMP protocol in addition to 
the OWAMP protocol. But, they would not be required to. This makes the changes 
completely backwards compatible for the already deployed clients and servers.

> 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.

If you have an IANA registry indicating the mode bits - there is no reason to 
have one to enumerate the new session request. Current OWAMP clients/servers 
won't care - it is not in the set of control messages they will use.

If an implementation decides to add that mode bit, then they will care to 
implement all of the messages from both protocols. So, it is true that some 
coordination will be necessary if either of these protocols need to evolve in 
the future, if it is done this way. But, that coordination is in RFC space, and 
it is not necessary in an IANA registry. (Other than the enumeration of mode 
bits, as I have said.)

> 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.

Ok - so this gets to the heart of the matter. What is the reason for wanting to 
put TWAMP on the same port? If it is to be able to have a single server that can 
run both kinds of tests - then it is important that clients/servers be able to 
determine capabilities of the server. So, the mode bit is very important for that.

If the point is that it was very close to what you needed, then fine. Use it, 
but don't interfere with the already deployed OWAMP servers and clients that are 
out there. Get a new port number assigned.

In my opinion, if you are using the already allocated and defined OWAMP port, 
the servers should be required to do OWAMP tests and optionally add TWAMP tests. 
Not the other way around as you have indicated. This is simply because there are 
already deployed OWAMP clients/servers and the expected usage of port 861 is 
already well defined.

jeff

_______________________________________________
ippm mailing list
ippm at ietf.org 
https://www1.ietf.org/mailman/listinfo/ippm