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

[Fortune HUANG <[e-mail]>]

Hi Al,
 
Thank you very much for your reply. Please see my response in-line below,
indicated by [Fortune].
 
 
Regards,
Fortune

  _____  

From: [e-mail] [mailto:[e-mail]] On Behalf Of Al
Morton
Sent: Thursday, March 18, 2010 9:56 PM
To: [e-mail]
Subject: Re: [ippm] Last Call: draft-ietf-ippm-twamp-session-cntrl
(Individual Session Control Feature for TWAMP) to Proposed Standard


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. 
 
[Fortune: OK. Thanks!] 





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. 
 
[Fortune: I don't think we need redundant fields to keep the two specs
similar, but I won't fight for it anyway. But could you tell me that if the
server accepts the SID in the way as described above, please?] 



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. 
[Fortune: If we need to consider this scenario seriously, maybe we need more
text on the behaviors of both the client and server for this scenario. But I
agree with you that this scenario seems rather unusual, and given my comment
missed the deadline of the IETF-LC, I can also accept it as it is.] 

IETF-wide Last Call ended on Monday,
Al