Clarify subscribe / annouce interaction

draft-ietf-moq-transport.md

@@ -710,7 +710,16 @@ subscribers for each track. Each new OBJECT belonging to the
 track within the subscription range is forwarded to each active
 subscriber, dependent on the congestion response. A subscription
 remains active until the publisher of the track terminates the
-track with a SUBSCRIBE_DONE (see {{message-subscribe-done}}).
+track with a SUBSCRIBE_DONE (see {{message-subscribe-done}}). A
+caching relay saves objects to its cache identified by the object's
+fulltrackname, group ID and object ID. Relays MUST be
+ready to process objects for the same fulltrackname from
+multiple publishers and the objects received are forwarded
+to active matching subscribers. If multiple objects are received
+with the same fulltrackname, group ID and object ID - a caching
+Relays MUST drop the received objects as duplicate if there exists
+already an object with the matching fulltrackame, group ID and
+object ID, in its cache.
 
 Objects MUST NOT be sent for unsuccessful subscriptions, and if a subscriber
 receives a SUBSCRIBE_ERROR after receiving objects, it MUST close the session
@@ -759,24 +768,47 @@ SUBSCRIBE_DONE, as defined below:
 | 0x6  | Expired                   |
 |------|---------------------------|
 
+### Graceful Publisher Relay Switchover
+
+This section describes non normative behavior that a subscriber MAY
+choose to implement to allow for a better users experience when a relay
+sends them a GOAWAY.
+
+When a subscriber receives the GOAWAY message, it starts of the process
+of connecting to the new relay and sending the SUBSCRIBE requests for
+all it's active subscriptions to the new relay. The new relay will send a
+response to the subscribes and once this has happened, the subscription
+to the old relay can be stopped with an UNSUBSCRIBE.
+
+
 ## Publisher Interactions
 
 Publishing through the relay starts with publisher sending ANNOUNCE
 control message with a `Track Namespace` ({{model-track}}).
+The annouce allows the relays to know which publisher to forward a
+SUBSCRIBE to.
 
 Relays MUST ensure that publishers are authorized by:
 
 - Verifying that the publisher is authorized to publish the content
   associated with the set of tracks whose Track Namespace matches the
-  announced namespace. Specifics of where the authorization happens,
-  either at the relays or forwarded for further processing, depends on
-  the way the relay is managed and is application specific (typically
-  based on prior business agreement).
+  announced namespace. Specifics of where the authorization and
+  identification of the publisher  happens either at the relays or
+  forwarded for further processing, depends on the way the relay is
+  managed and is application specific (typically based on prior business
+  agreement).
 
 Relays respond with an ANNOUNCE_OK or ANNOUNCE_ERROR control message
 providing the result of announcement. The entity receiving the
 ANNOUNCE MUST send only a single response to a given ANNOUNCE of
-either ANNOUNCE_OK or ANNOUNCE_ERROR.  When a publisher wants to stop
+either ANNOUNCE_OK or ANNOUNCE_ERROR.
+
+A Relay can receive announcements from multiple publishers for the same
+tracknamespace and it MUST respond with appropriate response to each of the
+publishers, in the same way as it would responds when processing ANNOUNCE
+from a single publisher for a given tracknamespace.
+
+When a publisher wants to stop
 new subscriptions for an announced namespace it sends an UNANNOUNCE.
 A subscriber indicates it will no longer route subscriptions for a
 namespace it previously responded ANNOUNCE_OK to by sending an
@@ -788,13 +820,52 @@ match on track namespace unless otherwise negotiated by the application.
 For example, a SUBSCRIBE namespace=foobar message will be forwarded to
 the session that sent ANNOUNCE namespace=foobar.
 
+When a relay receives an incoming SUBSCRIBE for a given namespace, for
+each publisher that has announced that namespace, the relay MUST send a
+SUBSCRIBE to that publisher unless it already has an active subscription
+to that publisher for the full track name in the incoming SUBSCRIBE.
+
+When a relay receives an incoming ANNOUCE for a given namespace, for
+each active subscription that matches that namespace, it MUST send a
+SUBSCRIBE to that publisher that send the ANNOUCE.
+
 OBJECT message headers carry a short hop-by-hop `Track Alias` that maps to
 the Full Track Name (see {{message-subscribe-ok}}). Relays use the
 `Track Alias` of an incoming OBJECT message to identify its track and find
 the active subscribers for that track. Relays MUST forward OBJECT messages to
 matching subscribers in accordance to each subscription's priority, group order,
 and delivery timeout.
 
+### Graceful Publisher Network Switchover
+
+This section describes non normative behavior that a publisher MAY
+choose to implement to allow for a better users experience when
+switching from WiFi to Cellular networks or visa versa.
+
+If the publisher detects it is likely to need to switch over, for
+example by seeing the WiFi signal is starting to get weaker, it sends a
+new an new ANNOUCE over the cellular network to the relay network. The
+relay will forward the matching subscribes and the client can start
+publishing on both the WiFi and cellular. Once the subscriptions have
+over to the new network, the publisher can stop publishing object on the
+old network. The relay will drop any duplicate objects received on
+both. the subscribes downstream from the relay do no see anything as
+changed, and keep receiving the objects on the same subscription.
+
+### Graceful Publisher Relay Switchover
+
+This section describes non normative behavior that a publisher MAY
+choose to implement to allow for a better users experience when a relay
+sends them a GOAWAY.
+
+When a publisher receives the GOAWAY, it starts of the process of
+connecting to the new relay and sending the announces, but it does not
+stop publishing data to the old relay. The new relay will send the
+subscribes and the publisher and at this point the publisher can start
+sending any new data to new relay instead of the old relay. Once data is
+going to the new relay, the announcement and connection to the old relay
+can be stopped.
+
 ## Relay Object Handling
 
 MOQT encodes the delivery information for a stream via OBJECT headers