Cisco Technology, Inc.

Meta Platforms, Inc.

Rohit Watve

Chandan Mishra

Sanjay Sane

Dinesh Ganapathy Dutt

Himanshu Baweja

Mohit Rajani

Shuo Li

Yi Xiao

Igor Slutsker

Csaba Halasz

Yunfei Si

Xiang Zhong

Adam Brice Flick

Markus Brunner

Exemplary embodiments relate to techniques for allowing a first user of a messaging platform to send follow-up message(s) to a second user after expiration of an allotted messaging time period without violating existing messaging policies based at least in part on opt-in messaging. The first user may perform an API call to an API of a messaging server to send a follow-up message request. Based on the request, the messaging server may send an opt-in message to the second user who may then explicitly opt in to receive a follow-up message from the first user. A qualifying response by the second user to the opt-in message may cause the messaging server to generate a unique token for the communicating pair. The first user may send the follow-up message to the second user by sending the message with the token.

Systems and methods for opt-in messaging

An online system allows users to exchange messages with other users, including entities such as businesses. A user, such as a business, may use a third party system to manage messages with users of the online system. The online system provides the third party information with instructions comprising tracking mechanisms that identify specific actions between users from messages exchanged between users. For example, if a user purchases a product from another user via a message thread, a tracking mechanism identifies the purchase and transmits information reporting the purchase and identifying users to the online system. Hence, the tracking mechanism transmits a description of an action and information identifying the users to the online system, and may also transmit additional information, such as a value of the action to a user. The online system may use the descriptions of actions for content targeting or measurement and reporting of actions.

Third party system reporting actions performed through the third party system by an online system user in response to messages received by the online system user

A method measures a resident delay for each port in a node in a network and a peer delay between each pair of neighbor nodes in the network. From these resident delays and peer delays, latency between each pair of neighbor nodes in the network is determined. The method includes weighting a route for a data packet going through the nodes in the network using the determined latencies. Each node includes a switch having switchable connections and is configured by a controller to send probe packets from an output port to a port in a neighbor node. The packet may include a time stamp and an identifier.

Passive network latency monitoring

An example method is provided and includes communicating a request packet to a first network element. The request packet is associated with a request for a list of flow parameters. The method also includes receiving a response to the request for the list of flow parameters, and communicating a test packet to initiate fault monitoring. The test packet is communicated to a second network element and the test packet includes at least one of the flow parameters provided by the first network element. The method also includes receiving a plurality of fault monitoring results. The results are limited to reflect multiple paths associated with the first network element.

System and method for providing proactive fault monitoring in a network environment

Techniques are provided to enable a switch in a layer-2 multipath network to determine connectivity of a path to a destination switch. At a source switch, user flow parameters are determined for user flow packets to be transported in the layer-2 multipath network to a destination switch. The sourced switch determines a number of hops from it to the destination switch based on the user flow parameters. Timestamping is activated for time-to-live expiry packets received at the source switch and for time-to-live expiry packets received at the destination switch. One or more probe packets having user flow parameters matching the user flow parameters of user flow packets are generated so that the probe packets use the same path taken by the user flow packets between the source switch and the destination switch. In addition, a time-to-live value corresponding to the number of hops from the source switch to the destination switch is included in a hop count field of the one or more probe packets. The time-to-live value distinguishes the one or more probe packets from user flow packets. The one or more probe packets are sent in the layer-2 multipath network from the source switch to the destination switch. Connectivity between the source switch and the destination switch is determined based on the one or more probe packets.

Probing specific customer flow in layer-2 multipath networks

Growing community of inventors

Santa Clara, CA, United States of America

Rohit Watve