Subject: [tsvwg] Non congestion controlled bandwidth in WebRTC draft-jennings-ice-rtcweb-timing-01

From: Cullen Jennings <[email-masked]>
Date: Mon, 11 Jul 2016 08:20:42 -0400

When WebRTC connections start, they send a bunch of STUN packets as part of ICE. Typically most of these STUN packets do not actually reach a valid destination so they have 100% packet loss from the point of view of the sender. This is discussed more in draft-jennings-ice-rtcweb-timing-01

We are trying to figure out how to seed up ICE so that it would do these checks faster and some of the questions that is coming up are:

1) in normal operation (not an evil attack) how much bandwidth is OK for a browser to use on a slow network when sending STUN packets but getting no responses? 

2) how should we measure bandwidth - basically how wide should the window be over which we totally bytes sent. Right now I am using the total bandwidth sent in a 100ms window to be the bandwidth estimate. Is this reasonable or is there a better way to talk about peak bandwidth ?

3) In a attack scenario where a huge number of browser all sending STUN packets to the same IP and port, what is a reasonable limit that each browser should not exceed (again assuming that the browsers have no response from this destination so it looks like 100% packet loss)? and for how long can this proceed ?

As background info, at the time this was written, the current release of major browsers would send significantly over 250 kbps (measured over 100ms window) to any IP and port in that the JavaScript specifies. I think the browser intend to move this 250 kbps. Note that the Javascript that causes the packets to be sent and selections the destination  might be in a paid advertisement that was put on a major web site. This can resulting in a huge number of page loads all executing the Javascript  in different browsers causing a large amount of bandwidth to be targeted at a particular IP and port. 

Thanks Cullen

And as a side note … any limits to what browsers should send here should likely be specified in  draft-ietf-rtcweb-transports which is currently in IETF LC ending July 21.