[Spud] Thoughts on monitoring a network of only UDP traffic

Dave Dolson <ddolson@sandvine.com> Tue, 26 July 2016 13:47 UTC

Return-Path: <ddolson@sandvine.com>
X-Original-To: spud@ietfa.amsl.com
Delivered-To: spud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17A7312DACE for <spud@ietfa.amsl.com>; Tue, 26 Jul 2016 06:47:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.206
X-Spam-Level:
X-Spam-Status: No, score=-3.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpxVWi5oRKXm for <spud@ietfa.amsl.com>; Tue, 26 Jul 2016 06:47:47 -0700 (PDT)
Received: from mail1.sandvine.com (Mail1.sandvine.com [64.7.137.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3A7A12DDB2 for <spud@ietf.org>; Tue, 26 Jul 2016 06:34:18 -0700 (PDT)
Received: from WTL-EXCHP-2.sandvine.com ([fe80::68ac:f071:19ff:3455]) by wtl-exchp-1.sandvine.com ([::1]) with mapi id 14.03.0294.000; Tue, 26 Jul 2016 09:34:17 -0400
From: Dave Dolson <ddolson@sandvine.com>
To: "spud@ietf.org" <spud@ietf.org>
Thread-Topic: Thoughts on monitoring a network of only UDP traffic
Thread-Index: AdHnQmgJlLiAfPGVT1Gzv/XBTpMRpQ==
Date: Tue, 26 Jul 2016 13:34:16 +0000
Message-ID: <E8355113905631478EFF04F5AA706E983104168B@wtl-exchp-2.sandvine.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.200.63]
x-c2processedorg: b2f06e69-072f-40ee-90c5-80a34e700794
Content-Type: multipart/alternative; boundary="_000_E8355113905631478EFF04F5AA706E983104168Bwtlexchp2sandvi_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/spud/Ma9453D3mN4zvlxMfPdlssRApE4>
Subject: [Spud] Thoughts on monitoring a network of only UDP traffic
X-BeenThere: spud@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Session Protocol Underneath Datagrams <spud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spud>, <mailto:spud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/spud/>
List-Post: <mailto:spud@ietf.org>
List-Help: <mailto:spud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spud>, <mailto:spud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2016 13:47:48 -0000

Consider a thought experiment for the year 2025...
- you are operating a network in a post-TCP world where PLUS and QUIC are standard
- all of the internet traffic is IP/UDP on arbitrary ports with encrypted payload
- you would like to know whether the network is functioning properly
   - does the network have enough capacity?
   - what latency are users/servers receiving?
   - is there a DDoS attack in progress?
   - are there rogue stack implementations that don't properly back off under congestion?

Today in 2016 operators can measure the health of the network by at least these methods:
- TCP round-trip time, such as absolute time to complete aspects of the 3-way handshake.
- TCP packet loss and retransmission, measured by tracking sequence numbers
- DNS response time (by correlating answers to queries)
- various protocol-aware voice quality and video quality measures

Even if you are using UDP protocols on the internet, you are benefiting from the TCP measurements that are proxy for the overall quality.
Of course none of these were designed (as far as I know) with this use in mind...

If TCP is to be replaced, we need to think about how what an operator can use in place of the TCP measurements to assess network health.

This is an opportunity to provide more explicit information to the network, *designed* for operations, (and not necessarily the same information used for end-point control.)
- should end-points expose sequence numbers and/or explicit loss information?
- should packets expose tokens that can be used to measure round-trip information?
- should senders be permitted to expose authenticating information to assist DDoS scrubbing?
   - could senders expose something that is difficult to fake?
- could there be a voluntary "debug mode" allowing network operators to collect a *lot* of information when users call the help desk?

And in the PLUS spirit, these could be optional, provided enough other traffic contained this information to provide enough samples for the operator.
Just as the presence of TCP allows all traffic to be managed, those exposing measurement information will benefit those that choose not to.

Thinking along these lines makes me in favor of PLUS but not a PLUS that is restricted to tube open/close.
I think there is a great opportunity to improve *both* privacy and network management.

Of course I'm also curious to hear how others expect networks to be managed in an all-UDP world.

-Dave