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

[Al Morton <[e-mail]>]

At 12:55 AM 3/18/2010, Fortune HUANG wrote:

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.

this thread should help:
At 10:37 PM 3/17/2010, Tina TSOU wrote:

At 10:26 PM 3/15/2010, Tina TSOU wrote:

In paragraph 3 of section 4.2, given that there is no change to the TWAMP-test packet format, I assume we use the exact TWAMP-test packet format as defined RFC5357, so that the SID is not carried in the test packets. My question is that how the reflector just whether a TWAMP-test packet belongs to the same session/SID or not. Since per definition the testing message does not include SID, how to differentiate the testing message of different testing sessions after multiple testing started?

The Request-TW-Session command includes sender address + port
and receiver address + port, and this is usually sufficient.

Can the server identify the corresponding SID based on sender address + port and  receiver address + port?

Yes, the server assigns the SID with all addr+port information in hand.

 
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.

Use of SID was decided in the OWAMP spec. We simply continue to
use it in TWAMP and it keeps the two specs similar.

 
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.
 

The client can resend, but in any case, the sender will stop sending
test packets.  At the reflector, resources are freed-up when it stops
a test, so this scenario seems rather unusual.

IETF-wide Last Call ended on Monday,
Al