Subject: Re: [ippm] Re: TWAMP protocol

From: "Jeff W. Boote" <[email-masked]>
Date: Mon, 01 Oct 2007 09:28:16 -0600

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
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ippm

---

From: "Hedayat, Kaynam" <[email-masked]>
Date: Wed, 17 Oct 2007 13:30:18 -0400

Jeff,

After examining your suggestion further we have realized that there is a
fundamental flaw in using the mode field for capability exchange. The
OWAMP protocol assumes that all servers at a minimum support OWAMP. That
is the mode field was not designed as a capability exchange mechanism
but rather a mode of communication exchange. The problem is that with
using the mode field an OWAMP client cannot detect a TWAMP only server
and will get rejections when requesting sessions (OWAMP clients/servers
MUST ignore the first 29 bits of the mode field).

There are 3 options that we have at this point:

1. Go with what originally was proposed. OWAMP servers will reject
Request-Session from TWAMP clients requesting a TWAMP session. We can
add text to the TWAMP draft and clarify this.

2. Add new bit definitions to the mode field. We will have to require
OWAMP clients/servers to change their implementation and not ignore the
first 29 bits of the mode field. There are two options here:
  2a mode bits as follows:
    8  - OWAMP only (current OWAMP implementations do not set bit 8)
    16 - TWAMP only

  2b mode bits as follows:
    8  - TWAMP only (current OWAMP implementations will not see these
bits)
    16 - OWAMP and TWAMP capability

3. Use a different "well-known" port for TWAMP

Authors are proponents of the first or the third option. The second
option will work but needs modification of currently implemented OWAMP
clients/servers.

Regards,
Kaynam & Al

> -----Original Message-----
> From: Jeff W. Boote [mailto:[email-masked]] 
> Sent: Monday, October 01, 2007 11:28 AM
> To: Al Morton
> Cc: Hedayat, Kaynam; Matthew J Zekauskas; IETF IPPM WG
> Subject: Re: [ippm] Re: TWAMP protocol
> 
> Al Morton wrote:
> > Jeff wrote:
> > 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:
> > ...
> > Values 1 or 3 seem applicable here. Also, in section 3.5 on 
> the Accept 
> > Session Message:
> 
> 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 
> 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.
> 
> > ...
> > (unless there's an OWAMP paragraph that says "close the 
> socket if an 
> > unexpected command is received"
> > 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:
> 
> 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:
> >> 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.
> > 
> > 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.)
> 
> > 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 
> 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
>

---

From: "Jeff W. Boote" <[email-masked]>
Date: Wed, 17 Oct 2007 13:44:07 -0600

Kaynam, Al,

Thanks for your detailed response.

> MUST ignore the first 29 bits of the mode field).

I guess I think that if TWAMP is attempting to use the OWAMP port, it follows 
that it should support the full OWAMP protocol. If instead, you are just 
attempting to make use of pieces of the OWAMP protocol for TWAMP, it probably 
makes sense for you to have a new port number allocated for TWAMP.

> add text to the TWAMP draft and clarify this.

There is no reason an existing OWAMP server would reject a TWAMP request (in the 
sense of a non-zero Accept value in an Accept-Session message). This will just 
be corrupt data from the point of view of an OWAMP server. There is nothing in 
RFC 4656 that says it must/should send a deny message when it receives a message 
with the first octet set to 5. That is invalid in the protocol, and there is no 
defined acceptable response message for corrupt data.

Specifically, from RFC 4656, 3.4 paragraph 3:

    The following commands are available for the client: Request-Session,
    Start-Sessions, Stop-Sessions, and Fetch-Session.

The Request-Session described here is from RFC 4656 with the first octet set to 
1, and not the TWAMP version with the first octet set to 5. None of the above 
listed commands have a 5 in the first octet.

To outline the consequences of this issue: an OWAMP server must key on the first 
octet to determine how long the specific command message is. An unknown value 
here does not give the OWAMP server enough information for it to know where the 
end of this unknown command is. So, it has no way to know how much to read to 
find where the beginning of the next command would be in the stream.

I have looked at our OWAMP server implementation, and I believe it will simply 
close the connection in this case (and log the error). But, I did not spend time 
to create a TWAMP request message to test this. In this case, clients will not 
have any indication of why the connection is being closed. It could be due to a 
network partition, or due to host events/firewalls. This does not seem to fit 
well with the principle of least astonishment.

Also, there are other implementations of OWAMP-Control out there. I have no idea 
how they would react to corrupt data in the control stream. Essentially, we are 
in unspecified behavior here.

>     16 - OWAMP and TWAMP capability

Would this require a new RFC for OWAMP? Or can something like this be added with 
an errata? I suspect this might be too much for an errata.

> option will work but needs modification of currently implemented OWAMP

I am in favor of the third option. I believe I have shown that the first option 
would also require modification of currently implemented OWAMP servers.

Alternatively, I would support a solution where the TWAMP protocol was in fact 
an extension to the OWAMP protocol. This could be done with the mode bits as I 
indicated previously. (I think I could probably find you an open-source 
implementation of the pieces you are missing... ;) )

jeff