Describe queue-name, policy and dead-letter queue aspects

Describe how to get past stumbling-blocks I met when setting up a service-bus queue pubsub.

Signed-off-by: Tomas Ekeli <tomas@eke.li>

daprdocs/content/en/reference/components-reference/supported-pubsub/setup-azure-servicebus-queues.md

@@ -181,6 +181,17 @@ When subscribing to a topic, you can configure `bulkSubscribe` options. Refer to
 
 Follow the instructions [here](https://learn.microsoft.com/azure/service-bus-messaging/service-bus-quickstart-portal) on setting up Azure Service Bus Queues.
 
+{{% alert title="Note" color="primary" %}}
+Your queue will need to have the same name as the Topic you are publishing to with Dapr. E.g. if you are publishing to the pubsb "myPubsub" on the topic "orders" your queue must be named "orders".
+If you are using a Shared access policy to connect to the queue that policy must have the ability to "Manage" the queue. To work with a dead-letter queue the policy must live on the Service Bus Namespace that contains both the main queue and the dead-letter queue.
+{{% /alert %}}
+
+### Retry policy and dead-letter queues
+
+An Azure ServiceBus Queue has a dead-letter quue by default. If you do not modify it the message will be retried the "Max delivery count" number of times (defaults to 10, can be set up to 2000). These retries will happen with very little delay before the message is put in the dead-letter queue.
+
+Since Dapr Pubsub has its own dead-letter queue -concept you can use this instead if you need control over retry-policy and you need to subscribe to the dead-letter queue (you probably should) you should set up a separate queue as that dead-letter queue in the same namespace, and a resilience component that defines how to retry on input.
+
 ## Related links
 
 - [Basic schema for a Dapr component]({{< ref component-schema >}})