Unless otherwise specified round trip time.
With TCP basically always round trip time as it's connection oriented. BDPs have always in my experience been calculated with round-trip time.
Remember the BDP is how much data can be traversing a connection at one time, and is used to calculate appropriate window size. The latency calculation has to be two way as in order to free up capacity in the transmission window data has to be acknowledged so the operation kinda runs, grossly simplified:
Server: Transmission of data, increment internal transmit window downwards - data considered 'in flight', unknown if received and processed
Client: Receipt of data, decrement receive window - data received, but not processed by TCP stack / application
Client: Transmission of acknowledgement(s), increment receive window per amount acknowledged, advertise window to server - processing complete, able to accept more data into TCP stack
Server: Receipt of acknowledgement(s), increment internal transmit window as appropriate - confirmed data received, no back off necessary, able to send more
Both advertise a window at the start of the connection, then both have internal windows, with server responding to feedback from client, and client's TCP stack using both information from itself and higher up the protocol stack as it tries to drain sockets to individual applications, so if client's TCP stack isn't able to drain properly it won't increment receive window as much, if at all, to invoke congestion control.