[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[ippm] RE: TWAMP protocol
Jeff,
Thank you for your comments. See reply below.
Regards,
Kaynam & Al
> -----Original Message-----
> From: Jeff W. Boote [mailto:boote at internet2.edu]
> Sent: Monday, August 06, 2007 6:35 PM
> To: Hedayat, Kaynam
> Cc: Matthew J Zekauskas; IETF IPPM WG
> Subject: TWAMP protocol
>
> 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.)
Although this is a good idea please note that we still need the IANA
Registry since the TWAMP Request-Session is a new message that is
different than the OWAMP Request-Session message. Your suggestion does
move up the control of the mode selection higher up in the protocol.
However, at this stage and with the amount of changes it introduces in
the protocol we feel that the current mechanism meets the needs of the
protocol.
>
> 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.)
TWAMP servers are meant to be implemented with low overhead on the
server (simply reflecting packets). The schedule made more sense in the
OWAMP case since the server processes the packets. That said, in TWAMP
the servers can certainly reject new sessions if they are over-burdened.
>
> jeff
>
_______________________________________________
ippm mailing list
ippm at ietf.org
https://www1.ietf.org/mailman/listinfo/ippm