USB Interrupt and Isochronous transfer bandwidth concept
In USB, guaranteed bandwidth also implies bounded latency, but not the other way around.

USB is organized into 1 ms time slices.  For interrupt transfer, the host is guaranteed to send a OUT packet to the device each slice.  Maybe it can be configured for once every N slices, I don't remember.  Interrupt packets are short, so you don't get to transfer much data, but you know the host will come around and ask periodically.

For isochronous, a fixed part of each 1 ms time slice is allocated to the device.  Not only will the host send the OUT packet each slice, but you can configure it to contain a specific amount of payload, or the IN reply packet to have a specific payload.  Obviously this allocates some of the fixed bandwidth to a particular device, so all devices can't have this with arbitrarily large data.  Since the available resource is finite, the host can refuse your device altogether.  This is one of the drawbacks of insisting on a fixed bandwidth.

There are also rules about how much of each 1 ms slice the host can allocate to interrupt and isochonous tranfers.  I think something like 20% must be left unallocated, which means the host will poll bulk transfer devices during this time.  There can be any number of bulk devices, so there is no guarantee how often the host will get around to polling any one device.

In most cases, the interrupt and isochronous transfers don't add up to much, so in practise most of the time is left over for bulk devices.  Usually the host will poll all bulk devices in a loop during any left over unallocated time.  If you're the only device on the bus, then bulk transfer will give you access to most of the bandwidth, whereas interrupt and isochronous still get the small dedicated bandwidth they are configured for.

Unless you really need some minimum bandwidth or latency, just use bulk transfers.