{'fraction_non_alphanumeric': 0.01556420233463035, 'fraction_numerical': 0.005188067444876783, 'mean_word_length': 5.225806451612903, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
DIFFERENT SOLUTIONS TO THE RSVP PROTOCOL SCALABILITY PROBLEM

The request of QoS from applications has led in the last years to the definition of architectures which extend the traditional best-effort Internet’s datagram delivery while remaining compatible with it. The Integrated Services architecture and the RSVP signalling protocol, simultaneously developed since 1993, are now used in stub-like areas of the Internet as part of an ‘application oriented’ QoS architecture. However the intrinsic complexity of the RSVP protocol has limited its usage in core areas of the Internet. Several mechanisms to reduce the extent of this problem have been proposed: in this paper we compare pros and cons of some solutions with an higher degree of maturity and standardisation.