Everything worth knowing, nothing that isn't.
Why a window exists at all
SMPP is asynchronous: you send a submit_sm and the SMSC replies with a submit_sm_resp, but you do not have to wait for that reply before sending the next PDU. The window is how many you are allowed to run ahead. With a window of 1 the session becomes request-response, and your throughput collapses to one message per round trip — on a 50ms link that is 20 messages a second regardless of what your contract says.
The arithmetic
Rough throughput is window size divided by round-trip latency. A window of 10 against a 50ms round trip gives roughly 200 messages per second on one bind; a window of 50 gives around 1,000. This is why two customers on identical commercial terms can see wildly different real throughput — one has tuned the window and the other has not. Raising the window costs nothing on your side except memory for the unacknowledged PDUs.
Why you cannot just set it to 1,000
The window is agreed with the operator or provider, and exceeding it gets you ESME_RTHROTTLED responses or a dropped bind. The SMSC has to hold state for every unacknowledged PDU too. Beyond a certain point the bottleneck moves from the window to the SMSC's own submission rate, and a larger window only deepens a queue you cannot drain. Agree the window and the TPS ceiling together, and treat them as one setting.
Multiple binds and ordering
When one bind is not enough, the answer is more binds rather than an unbounded window — most providers allocate throughput per bind. Be careful with message ordering: PDUs across separate binds have no guaranteed relative order, so a multi-part message or a sequence a user will read in order should stay on one bind. Keep an enquire_link running on each so an idle bind is not silently dropped.