The “best effort” service as a deployment success factorMichael Welzl

IAB ITAT Workshop4-5. December 2013

2

Disclaimer

I can’t guarantee ahigh quality talk

But I’ll do my best

3

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– a very simple story about very obvious things, but an

“outsider’s look” at things

• We go back in time, to the 90’s…

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

5

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!

6

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….

7

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 as

draft-lai-tsvwg-normalizer– Latter: indirectly being proposed via draft-ietf-rtcweb-qos

8

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 6555 and draft-wing-http-new-tech-01

9

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

10

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.”

11

Yet again, a chicken-egg problem

• Applies equally to QoS and transport protocols

• Two simple measures to break this vicious circle1. Hide the mechanism (protocol, QoS scheme) from

the applications; expose a service

2. Provide services in a best-effort fashion

• Why these two things?Next slides…

12

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

13

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-qos shows 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)

14

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

15

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

16

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/

17

Thanks!