Browse Prior Art Database

OPTIMIZING IN-BAND NETWORK-TO-APPLICATION FEEDBACK

IP.com Disclosure Number: IPCOM000239325D
Publication Date: 2014-Oct-29
Document File: 5 page(s) / 167K

Publishing Venue

The IP.com Prior Art Database

Abstract

Presented herein are techniques for network element buffering of an endpoint-generated packet for use in real-time signaling to endpoint(s) without in-network packet generation, avoiding security issues. These techniques speed up network-to-application interaction without introducing an additional implication that attracts or introduces packet spoofing.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 41% of the total text.

Page 01 of 5

OPTIMIZING IN-BAND NETWORK-TO-APPLICATION FEEDBACK

AUTHORS:

Pål-Erik Martinsen Dan Wing Herb Wildfeuer

CISCO SYSTEMS, INC.

ABSTRACT

    Presented herein are techniques for network element buffering of an endpoint- generated packet for use in real-time signaling to endpoint(s) without in-network packet generation, avoiding security issues. These techniques speed up network-to-application interaction without introducing an additional implication that attracts or introduces packet spoofing.

DETAILED DESCRIPTION

    Using in-band signaling to provide feedback from the network to an application as described in the IETF draft-martinsen-tram-discuss can be slow as the network element needs to wait for a Session Traversal Utilities for Network Address Translation (NAT) (STUN) message in the stream to transport any event information to the application. This is known in the art as "piggybacking." The interval at which STUN messages are sent may vary from 1 to 5 seconds. Waiting 1 to 5 seconds to pass event information from the network to the application is too slow to solve for congestion in, for example, Wi-Fi™ use cases.

    Reducing the network response time would significantly increase the usefulness of in-band signaling between the application and the network. One solution to the problem is to allow the network element to generate and send a second packet. However, that is a packet amplification (receive one packet, generate two packets) and would likely become a vector for bandwidth Denial-of-Service (DoS). Increasing the frequency the application sends STUN messages can also solve the problem. However this would lead to more packets in the stream and higher bandwidth usage. It would also cause higher

Copyright 2014 Cisco Systems, Inc.
1


Page 02 of 5

processing cost on the network elements as there will be more STUN packet to process. To avoid excessive processing cost, network elements rate limit the processing of STUN packets.

    In any given network topology there may be network elements, such as routers, capable of leveraging information sent from the application using an in-band protocol, such as STUN. The network elements can also add information to convey specific event notification such as congestion back to the application as described in the above IETF draft.

    A Software-Defined Network (SDN) controller can also be part of the network topology as shown in FIG. 1 below:

FIG. 1

    Presented herein is a solution that allows a network element to remove a STUN packet from a flow and buffer it (inside the network element itself, or in the SDN controller). In the future when an event occurs, the buffered packet will be inserted back into the flow and will send information regarding the event towards to the application. Such packets are marked by the endpoint as "storable" by the network element(s). When STUN is used to transport the piggyback information, the application will add a STUN attribute after the INTEGRITY attribute, which allows the. n...