The “best effort” service as a deployment success factor Michael Welzl

The “best effort” service as a deployment success factorMichael Welzl IAB ITAT Workshop 4-5. December 2013

Disclaimer I can’t guarantee ahighquality talk But I’ll do my best 

The Internet and I • This is a story of how I perceived the Internet when I learned about it for the first time • Through my naïve eyes, many things should have been better & I was surprised that they weren’t • I’m still naïve today, hence this talk • avery simple story about very obvious things, but an “outsider’s look” at things • We go back in time, to the 90’s…

From http://blog.sendmemobile.com/music-humor/ten-1990s-artists-who-need-a-comeback

Why did the Internet take off? • When I first learned about it, I heard/read: • Hourglass with IP in the middle • IP over everything, everything over IP • IP over everything was a big deal to me.It is a big deal, even today, right? • How can the same network technology work over fiber links and avian carriers? • Only by not making QoS promises!

But this was the time of QoS • And it looked so wrong! (rather, then: confusing) • I read about Alternative Best Effort (ABE) Service (Paul Hurley, Jean-Yves Le Boudec, Patrick Thiran) and thought, oh, THAT’s how they’ll do it! (I’m still surprised it’s not) • I also read about adaptive multimedia applications:seemed to be a QoS alternative that’s more scalable and cheaper to implement • QoS Congestion Control became a continuous spectrum in my mind • CC. tries hard but never promises….

Simple Michael’s thought • Best effort made it succeed, so of course these things have to be done in a best effort way? • E.g., we could just try stuff, and fall back if it doesn’t work • QoS • Do something ABE’ish, or try and fall back • Former: currently being proposed asdraft-lai-tsvwg-normalizer • Latter: indirectly being proposed via draft-ietf-rtcweb-qos

Simple Michael’s thought /2 • Not just QoS! E.g. why does everyone complain about ECN non-deployment but nobody just tries if it works, with a fallback? • Currently being proposed as draft-kuehlewind-tcpm-ecn-fallback • What about IPv6? SCTP? • RFC 6555and draft-wing-http-new-tech-01

Holy moly, exciting times! • But the API between applications and the network is lagging behind • How do you provide a low-latency-but-less-bandwidth service to a flow when you don’t know that it wants it? • How do you make a flow benefit from faster delivery of out-of-order packets when all flows expect TCP-like service? • Yes there are things that can be done, but the current API is very limiting

RFC 2990 (“Next Steps for the IP QoS Architecture”)published November 2000 “No network operator will make the significant investment in deployment and support of distinguished service infrastructure unless there is a set of clients and applications available to make immediate use of such facilities. Clients will not make the investment in enhanced services unless they see performance gains in applications that are designed to take advantage of such enhanced services. No application designer will attempt to integrate service quality features into the application unless there is a model of operation supported by widespread deployment that makes the additional investment in application complexity worthwhile and clients who are willing to purchase such applications. With all parts of the deployment scenario waiting for the others to move, widespread deployment of distinguished services may require some other external impetus.”

Yet again, a chicken-egg problem • Applies equally to QoS and transport protocols • Two simple measures to break this vicious circle • Hide the mechanism (protocol, QoS scheme) from the applications; expose a service • Provide services in a best-effort fashion • Why these two things?Next slides…

Breaking the vicious circle • Someone has to break the deadlock • We can take the role of OS / middleware developers • Give app designers a very easy-to-use API that can give them lots of benefits • Quantify these benefits (provide exemplary proof) • Do whatever we can for legacy applications by enhancing higher-level, already transport-agnostic APIs • Again, quantify the benefits - “Build it and they will come!” • Once applications use new protocols / QoS mechanisms, there’s a reason to enable them in the network

Best-effort service provisioning • Why? • A lot of the incentive for app developers is ease-of-use; best effort always “works” (never says “no”) • draft-ietf-rtcweb-qosshows that it’s considered worthwhile (but only one app) • How? (Remember: best-effort path assumed;no latency / throughput guarantees) • Faster out-of-order delivery (e.g. SCTP) • Fallback: slow in-order delivery (TCP) • Partially unreliable delivery (e.g. SCTP) • Fallback: reliable, but throw away if it arrives too late (TCP)

More best effort fallbacks • More capacity via multiple paths (e.g. MPTCP) • Fallback: less capacity via one path (TCP) • Lower latency at the potential cost of throughput (e.g. more FEC in some NC-TCP-variant, or some queuing behavior via a DSCP) • Fallback: a lot of latency via TCP • Yes, TCP fits for a lot of things 

Sound lame? • I’m sure it’s not • And remember, I’m a visionary! • This would give more freedom to the market • Different choices of protocols in middleware x vs. y,or OS A vs. OS M vs. OS L • Different support for protocols or QoS mechanisms by ISP1 vs ISP2 • New impetus for the middlebox market

Conclusion – a plea • Many years have passed, but the transport layer is the same same same. • Can we please fix at least this bit now? • Else we’re only going to get even more proprietary chaos-over-UDP competing with boring-old-TCP • Proposed Transport Services BOF: https://sites.google.com/site/transportprotocolservices/

Thanks!

The “best effort” service as a deployment success factor Michael Welzl