Subject: [ippm] Last Call: draft-ietf-ippm-twamp-session-cntrl (Individual Session Control Feature for TWAMP) to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 1 Mar 2010 06:38:48 -0800 (PST)

The IESG has received a request from the IP Performance Metrics WG (ippm) 
to consider the following document:

- 'Individual Session Control Feature for TWAMP '
   <draft-ietf-ippm-twamp-session-cntrl-04.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2010-03-15. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ippm-twamp-session-cntrl-04.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17883&rfc_flag=0

---

From: Fortune HUANG <[email-masked]>
Date: Thu, 18 Mar 2010 12:07:49 +0800

Dear all,
 
I have some questions about this draft below. Sorry for being a little late.
 
1. It is not clear to me how the server or the reflector use the SID
specified in the request from the client. The SID doesn't seem to be used to
correlate the test packets and the accepted sessions because there is no SID
in the test packets. 
 
2. In section 3.3, I think the SIDs may not need to be carried back to the
client. Assuming the SID is accepted in sequence with no discrimination, the
client can figure out the list of accepted SIDs with the accepted number of
sessions.  Suppose the client requests for SID1, SID2, SID3 and SID4 in
sequence, can the server accepts only SID1, SID3 without accepting SID2? If
it can do that, how does the server differentiate SID3 and SID2? If it can
not do that, that I think the server can return a acceptance count to the
client, e.g. 2 for accepting SID1 and SID2, 3 for accepting SID1, SID2 and
SID3.
 
3. In section 3.5, What can the client do if told by the server that some
the sessions can not be stopped? To resend the stop request? But in that
case, a simpler way would be that the server could try to stop the sessions
again without any stop request resent from the client. The signalling could
be reduced in this way.

Regards,
Fortune