Frequently asked questions

  1. Flow-aware networking
    1. Why does the network need to be flow-aware?
      Basically because other approaches that are only aware of datagrams (the best effort network) or of class of service aggregates (Diffserv) are unable to offer meaningful QoS guarantees at flow level.
    2. Does flow-aware imply a solution like Intserv or ATM?
      No. We claim it is possible to provide flow-level guarantees by relatively lightweight mechanisms that maintain the current best effort user-network interface.
    3. What service guarantees are provided by Cross-protect?
      Bounded packet delay and loss for streaming flows; minimum throughput for elastic flows. In overload conditions, packet level performance is only guaranteed for streaming flows whose peak rate is less than a certain operator chosen threshold.
    4. FAN has been designed with current services and technology in mind; is it necessarily future proof?
      The performance of Cross-protect is largely insensitive to flow traffic characteristics (size distributions, correlated arrivals,...). The rate threshold used to distinguish flows with guaranteed low packet latency can be increased in line with link bandwidth and streaming application bit rate. Necessary scale economies of networking imply that link bandwidth will always be two or more orders of magnitude greater than individual application flow rates (to ensure adequate multiplexing efficiency).
    5. Have all the problems to do with implementing FAN been solved?
      No! We see flow-awareness as a necessary enhancement to the Internet which avoids the failings of proposed QoS architectures like Diffserv i[IEEE]. We believe the Cross-protect mechanisms constitute an attractive lightweight solution for the core network. Additional mechanisms are certainly necessary in the access network. There remain many outstanding issues, as highlighted in the partial answers to these FAQ.
  2. Fair queueing
    1. Is per-flow fair queuing sufficient?
      In the absence of overload, fair queuing ensures potentially high rate elastic flows do not disrupt the performance of concurrent lower speed streaming and elastic flows and this is generally all that is required. Priority Fair Queuing further reduces packet latency for the low rate flows [HPSR04, ITC19].
    2. Why not increase "utility" by using weighted fair sharing?
      The usual assumption that utility can be expressed as a function of instantaneous flow rate is largely meaningless when (realistically) considering finite size elastic flows. Models of statistical bandwidth sharing (i.e., with a dynamic population of flows) show that expected response times are generally only marginally improved as the sharing weight increases [BM]. Unweighted fair sharing is much simpler to implement.
    3. Why not improve elastic flow performance using size-based scheduling?
      Though policies like SRPT, LAS and MLPS are known to improve throughput performance of elastic flows on an isolated bottleneck, performance is not necessarily significantly better than fair sharing in a network setting. Fair queuing is much simpler to implement than size-based scheduling.
    4. Is it also possible to provide hard bandwidth guarantees for certain flows?
      Cross-protect only provides statistical performance guarantees at packet level for flows of rate less than a certain threshold. To provide guaranteed rate tunnels would require additional mechanisms (like MPLS tunnels with ingress rate shaping). These can co-exist with Cross-protect which would then be used to regulate sharing of residual bandwidth. The sharing of tunnel bandwidth between its flows could also be controlled using Cross-protect.
  3. Admission control
    1. What is the role of admission control?
      The main role of admission control is to preserve performance in exceptional overload situations when offered load (flow arrival rate x mean flow size) exceeds link capacity. This occurs notably in case of failures. Admission control should be able to handle the sudden surge of (apparently new) flow arrivals resulting from route changes and then maintain useful throughput as long as the overload lasts.
    2. Don't users generally prefer reduced throughput rather than no throughput at all due to blocking?
      It is more a question of a local optimum versus a global optimum. In case of persistent overload, to accept all new flows would lead to a situation where throughput decays to a point where some flows are abandoned (otherwise throughput would continue to decrease since, in overload, more flows arrive than can complete). The link is fully used but per-flow quality is generally poor. Capacity may also be wasted on partially completed flows. Admission control aims to maintain full link utilization while keeping the throughput of admitted flows high enough.
    3. Why would users accept the implicit blocking signal of packet discard and not continue to send additional packets?
      This is a likely behaviour and needs to be taken into account in designing the admission control algorithm. An interesting possibility is that the network allows multiple path choices. Retransmitted packets might test an alternative path and thus avoid blocking. Admission control is seen here as an essential component of adaptive, traffic-sensitive routing.
    4. Doesn't distributed admission control lead to inconsistencies with flows admitted on some links and blocked on others?
      Implicit admission control is performed independently on several links along a flow's path allowing a flow to be admitted on some links and blocked on others. However, the flow will not proceed until it is accepted (i.e., protected) on every link. The only consequence of accepting a flow that is blocked elsewhere is to maintain flow state in the protected flow list until the application has ceased to send new packets for the time out period. There is no wastage of resources in the data path.
    5. What key can be used to distinguish priority flows in a system with discriminatory blocking?
      It is clearly necessary to employ a key that cannot be spoofed by malicious users. The key might be derived from the lower layer headers indicating the flow belongs to a VPN, for instance. Flows to emergency services identified by a known destination address could be protected. Discriminatory blocking could also depend on the flow's incoming interface (e.g., to prefer local traffic to transit traffic).
  4. Complexity, implementation
    1. Is per-flow fair queuing scalable?
      The number of flows that need scheduling (they actually have a packet in the queue) is relatively small (100s) compared to the number of flows in progress (100s of thousands). The number to be scheduled depends on link load but not on link capacity [HOTNETS, SIGMETRICS, ANCS].
    2. Is implicit per-flow admission control scalable?
      Admission control needs to be aware of the identities of flows in progress in order to identify new flows. This leads to state requirements that are much greater than those of fair queuing. However, realization of very large flow tables is feasible and relatively inexpensive (according to [Anagran]). There is scope for optimizing the size and complexity of the flow table [ANCS].
    3. Is it necessary to implement Cross-protect on every link?
      Cross-protect can be implemented incrementally, starting with heavily loaded, vulnerable or costly links. Once developed and implemented, the proposed mechanisms are not particularly expensive. They could be included in standard line cards and rolled out progressively.
    4. Can Cross-protect be combined advantageously with other traffic control mechanisms?
      FAN could be used on the segment of capacity left in alternative architectures for so-called best effort traffic. It could also be applied within an MPLS tunnel. If tunnels with guaranteed rate (e.g. by ingress shaping) were used to interconnect edge routers, Cross-protect would be used uniquely within these routers there being no possibility of congestion in the label switching routers.
    5. Does FAN/Cross-protect bring additional operational expenditure?
      The proposed architecture preserves the user-network interface of the current best effort Internet. All users have basically the same SLA with respect to flow quality of service. There are no bandwidth brokers or policy servers to manage and no new signalling protocols to be implemented. The reduced opex of the proposed flow-aware architecture is one of its major advantages compared to alternatives.
    6. Can Cross-protect be implemented in an input-queued switch fabric?
      Current proposals assume output buffered switching. The design could be extended to account for input queuing. Most switch fabrics implement scheduling (e.g., for Diffserv PHBs) only at the output relying on speed-up to avoid internal blocking.
    7. How can we perform flow-aware networking if flows are masked by tunnels?
      It is assumed in our proposals that flows can be identified by inspecting the IP packet header. This is usually possible even when a packet is encapsulated in layer 2 headers. It would not be possible for 5-tuple IPv4 flows in an IPSEC tunnel, however, since port numbers are then masked. The flow label field in IPv6 allows a flow to be identified from just the layer 3 header and would avoid the IPSEC problem.
    8. Is FAN compatible with the implementation of VPNs?
      Many reasons for implementing VPNs (addressing, security,?) are orthogonal to the performance concerns addressed by FAN. We believe VPN traffic needs the flow-level guarantees provided by Cross-protect mechanisms as much as any other kind of traffic. Guaranteed rate tunnels between VPN end points can be used in conjunction with Cross-protect. To meet user requirements for QoS guarantees for less well defined demands is the primary motivation for the development of FAN. The pretended guarantees of alternative architectures (e.g., latency less than x ms for traffic respecting given CIR and burst tolerance parameters) are largely illusory.
  5. Denial of service
    1. Can users avoid flow blocking by maintaining a stream of keep-alive packets between a given source and destination?
      This is certainly possible. However, it is unlikely that more than a few users would find this worthwhile. Admission control would still be an effective overload control if it blocked a sufficiently large proportion of flows arriving from other users.
    2. Can users saturate the protected flow table by sending a lot of single packet flows (e.g., by using a different flow id for every packet)?
      To be effective, this attack would need to occur at the same time a link was congested. In the absence of congestion, flows do not need to be protected and performance would be unaffected by saturation of the protected flow list. By recording flow state, FAN should make it easier to detect and prevent DoS attacks including this one.
    3. Can users gain more than a fair share by setting up several flows in parallel?
      Only users with high rate access can do this. The fair rate provided by a backbone link is usually much higher than the access line rate of most users. Since the fair rate is high, users don't really need to cheat. By recording flow state, FAN should make it easier to detect and prevent DoS attacks including this one.
    4. Can users ensure low latency for a high rate flow by disguising it as multiple lower rate flows?
      Only users with high rate access can do this. The fair rate provided by a backbone link is usually much higher than the access line rate of most users. Since the fair rate is high, users don't really need to cheat. By recording flow state, FAN should make it easier to detect and prevent DoS attacks including this one.