Transcript The “best effort” service as a deployment success factor

The “best effort” service as a deployment
success factor
Michael Welzl
IAB ITAT Workshop
4-5. December 2013
Disclaimer
I can’t guarantee a
high quality talk
But I’ll do my best 
2
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…
3
From http://blog.sendmemobile.com/music-humor/ten-1990s-artists-who-need-a-comeback
4
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!
5
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….
6
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
7
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-tcpmecn-fallback
• What about IPv6? SCTP?
– RFC 6555 and draft-wing-http-new-tech-01
8
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
9
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.”
10
Yet again, a chicken-egg problem
• Applies equally to QoS and transport protocols
• Two simple measures to break this vicious circle
1. 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…
11
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 higherlevel, 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
12
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)
13
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 
14
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
15
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/
16
Thanks!
17