Subject: [ippm] very drafty IANA section for twamp

From: Matthew J Zekauskas <[email-masked]>
Date: Mon, 06 Aug 2007 12:53:11 -0400

Here is my initial public cut on the text for TWAMP. I still have some
questions, and perhaps working group members have an opinion (or better
way to state some of the text).

If it does not already do so, perhaps we should say somewhere
"TWAMP-Control" is an update of OWAMP-Control for two-way measurements,
rather than just calling it "TWAMP-Control".  I think it might even say
that somewhere...  [this is a question from me]

x == 8 in the current draft:

--=== begin text ===--

x. IANA Considerations

IANA has allocated a well-known TCP port number (861) for the
OWAMP-Control part of the OWAMP [RFC4656] protocol which also
applies to the TWAMP-Control part of the TWAMP protocol.

Since TWAMP adds an additional OWAMP-Control command to the OWAMP-Control
specification, and describes behavior when this control command is
used, we will create an IANA registry for this field.  The field is
not explicitly named in [RFC4656] but is called out for each command.

x.1 Registry Specification

IANA will create an OWAMP-Control Command registry.  OWAMP-Control
commands are specified by the first octet in OWAMP-Control messages as
shown in section 3.4 of [RFC4656], and modified by this document.
Thus this registry may contain sixteen possible values.

x.2 Registry Management

Because the registry may only contain sixteen values, and because
OWAMP and TWAMP are IETF protocols, this registry must only be updated
by "IETF Consensus" as specified in [RFC2434] -- an RFC documenting
the use that is approved by the IESG.  We expect that new values will
be assigned as monotonically increasing integers in the range [0-15],
unless there is a good reason to do otherwise.

x.3 Experimental Numbers

[RFC3692] recommends allocating an appropriate number of values for
experimentation and testing.  It is not clear to the authors exactly
how many might be useful in this space, nor if it would be useful that
they were easily distinguishable or at the "high end" of the number
range.  Two might be useful, say one for session control, and one for
session fetch.  On the other hand, a single number would allow for
unlimited extension, because the format of the rest of the message
could be tailored, with allocation of other numbers done once usefulness
has been proven.  Thus, this document will allocate one number, the
next sequential number 6, as designated for experimentation and
testing.

x.4 Initial Registry Contents

OWAMP-Control Command Registry

Value  Description             Semantics Definition
0      Reserved
1      Request-Session         RFC4656, Section 3.5
2      Start-Sessions          RFC4656, Section 3.7
3      Stop-Sessions           RFC4656, Section 3.8
4      Fetch-Session           RFC4656, Section 3.9
5      Request-TW-Session      this document, Section 3.5
6      Experimentation         undefined, see Section x.3.

--=== end text ===--

New Normative Reference: Guidelines for IANA Considerations, RFC 2434/BCP 26
New Informative Reference: Assigning Experimental and Testing Numbers
Considered Useful, RFC 3692/BCP 82

Other questions and issues:

* should we have 0 as reserved?
* any need to mention "network byte order" here in this document?
* is the case of the headings consistent with the rest of the document?
* does the initial para need a revision?  it is carried over from the
current draft.

* we should probably write an Errata request for 4656 that points to
this document, so there is a forward reference.

--Matt

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

---

From: "Jeff W. Boote" <[email-masked]>
Date: Mon, 06 Aug 2007 16:35:01 -0600

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

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

jeff