Skip to main content

Transcript Day 1: Technical Sessions

Slides IAB Workshop on Stack Evolution in a Middlebox Internet (semiws) Team
Title Transcript Day 1: Technical Sessions
Abstract Transcript Day 1: Technical Sessions
State Active
Other versions plain text
Last updated 2023-02-10

Technical Session 1: The bigger picture: what is the problem? how did we get
here? (11:20 - 12:45)

Intro slides (2-5)
- Take note of earlier work, including RFC 5218 and RFC 7305.
- NAT has been recognized as a challenge to the Internet architecture for a
very long time. - IAB Stack Evolution Program is the reason for the workshop. 
Can we find a way forward in light of today's Internet. - The waist of the
hourglass has become HTTP or HTTPS.  Some people disagreed with this picture,
especially the picture needs to recognize various types of tunnels and the
increased demand for encryption.

Ken's slides
- The "path" (as distinct from the "route") is becoming a first class concept.
- Incentives are aligning.
- Recognize need for evolution and inovation.
- Components of a solution include a framework for composing end-to-end
functions and a mechanism for negotiate (or at least determine) path
        - Fine-grained control
        - Integrate security

Christian's slides - Secure Transport Tussle
- So far, the middleboxes are winning; could not deploy ECN!
- Need to focus on the incentives for the people that are choosing to deploy
middleboxes.  We see partial success with UNSAF NAT Traversal. - UDP w/
encryption (e.g., QUIK) is a secure transport.  HTTPS is a fallback where UDP
is blocked. - Gaming is even more sensitive to latency than VoIP. - Deploy on
the Internet of today, and the network will evolve to do things better for that
application if it becomes

* jana: If you don't align incentives, things don't move.  Jim Getty's
"downward deployability" * brian: webrtc is that

Thaler's slides - It's all about incentives
- slide 15: RFC 5218 - it is best if there are significant positive net value
at each organization where a change is required. - slide 16: Tussles stem from
conflicting incentives in a free market.
        - e2e protocol innovation
        - some middleboxes that provide optimization
        - firewalls are worried about untrusted entities
        - inter-protocol proxies are inherent in innovation

* Ken: what does the tussle look like for end users?
* Dave: metrics in Consumer Reports about which ISP to use
* Brandon: not always provider vs. provider, it might also be Akamai
* Dave: might be multiple CDN providers in competition
* Bob: also departments inside a single ISP
* Christian: history of this backfiring
* Brian: if it's in hardware, by the time you realize it's a problem, nobody
knows about it anymore * Christian: tussle between a smart network and a
high-capacity simple network * Erik: in addition to security, there is also
protection for a business model or current revenue stream. * Black: heading
toward edges, TURN servers are now price of doing business, could be a way to
make progress * Ted: TURN servers have to be on the public side when deployed,
but don't always have to be deployed * Black: increase the incentives to deploy
TURN * Wing: TURN servers don't solve.  If i don't trust the entity, I won't
allow it.  Bittorrent over WebRTC.  Enterprise's job is to provide "safe" bits.
Policies are more complex than "make WebRTC work".  Definitions of "good" and
"bad" are fuzzy.  End systems and middleboxes both have a role in the final
acceptable solution. * Christian: adding VoIP to existing FW was hard; keep
media gateways separate. Adding more middleboxes to "safely" transition a
firewall is the wrong architecture.  It does not scale for each new
application. * Joe: we should at least try to do e2e, not send everything
through TURN * Black: TURN servers might be a place to add value, though * Ted:
TURN server allows application to make a choice about the path, client gets to
say it wants a *service* on the path.  Also policy breaks path when it might or
might not be good.  Split-client proxy approach.  DPI will be needed to
determine what is on-path if we do not develop a different abstraction of the
network stack. We need an API to the path to make progress. * Bob: middleboxes
that are needed for inter-protocol are deployed as part of a transition, but
then they never go away. * Eliot: what is an endpoint? * Jana: when the middle
don't have options, they add what looks like a new endpoint. * Erik: A very
different example of middleboxes are used to improve performance over a
satellite link.  They try very hard to be transparent, but they sometimes break
things. * Thaler: NAT64 doesn't work for anything but UDP or TCP * Brian: it's
a change to the contract * Christian: Skype relays compare to NAT64 relays. 
open relays never work, never deployed because incentives don't align.  Skype
can charge for relays, so there was strong incentive. * Jana: i've stopped
thinking about TCP as e2e, it's happens for anything that gets popular * Eliot:
smart objects are also "the user". how do you empower a lightbulb? * Mirja:
control over middleboxes to client, but is there a different class of
middlebox? there are at least two classes of middleboxes -- ones where the end
point can get some control and and ones where they cannot. * Thaler: yes. 
attackers on the inside.  this is why there's a tussle. * Black: think about
smart objects a bit differently.  The end user is actually the person that
deploys the lightbulb.  But the person that installs it might use the API at
the lightbulb server.

- slide 17: Upper layer protocols:
        - want it to work everywhere (needs to look like HTTPS)
        - want to be efficient (throughput, latency, power, and so on)
        - want to be as simple as possible (easy to diagnose, maintain, ands
        mall footprint)
  -> Can get one or two, but not all three.  People make tradeoffs.

* Christian: it's not conflicting incentives, we have to make engineering
choices.  if you have a layer that allows you to pick a server closer to you,
it decreases latency, so adding layers doesn't always add latency * Brandon:
path API * Gorry: layers may be a figment of protocol design seen by network
designers, not elsewhere. * Joe: adding a layer doesn't always require added
round trips * Jana: layers might not need bits on the wire.  they might be
notional * Michael: the incentive is to get it to be as efficient as possible *
Thaler: example is happy eyeballs * Costen: typically people think about it as
fallbacks from optimal * Thaler: other people will take UDP as a baseline *
Brandon: Flexibility / deployability might be the tradeoff * Eliot: sometimes
the scope is Enterprise, sometimes it's the House * Christian: too many
fallbacks are bad; it brings too much complexity. * Brian/Eliot: "scope" is
also a dimension to the tradeoff. * Aaron: it is not back and white -- need to
make compromises in all of these dimensions. * Colin: people will not agree on
the dimensions that are part of the tradeoff. * Gorry: robustness is also
important. And, need to avoid an arms race. * Erik: operational complexity is
also important, and it really needs tools. * Mirja: "incentives" is the wrong
word.  Rather, we need to think about these as requirements for protocol
designers.  Incentives apply to adoption of the protocol.

Felipe's slide (19) presented by Brian
- Problem 1: Middleboxes are common
        - They enhance network functionality
        - Not always opaque

* Aaron: Jim has done work
* Christian: ad insertion something people want?
* Bob: only in the US do people buy their own CPE
* Christian: cable companies aren't trusted
* Bob: NFV moving SPs to software, which should make things update more
frequently, but can't rely on it * Spencer: Jari lost an AP in his house. *
Brian: if we go too far we have to fix management * Brandon: the more the SPs
blend into content providers, the more likely that the hardware in the
residence is under control of the SP * Black: one of the drivers to having
people deploy hardware at home is features. Homeowners add boxes to enable
features not supported by their provider.

Technical Session 2: The role and rule of middleboxes: intro and discussion
(14:15 - 15:30)

Benoit's slides
- describes the plan for a classification project /  middlebox traceroute

* Lars: Such a study was done and indicated that the behavior is unstable
enough that such a study is infeasible. Home gateways have different behavior
on different ports, and on the same port over time. * Miroslav: his study saw
the same * Benoit: Yes difficult, but trying to classify. Maybe reliability
isn't required. * Brandon: Needs a broad distribution across client space. *
Benoit: No plan for that yet. * Spencer: Same concern as Lars. What can help
guide identifying the range? Which types might be more predictable and which
less? * Bob: Don't look for behaviors, look at vendor brochures if you want to
see the range of what boxes claim to do * Brian/Mirja: Maybe do a session on
this tomorrow. Some discussion of discussion scope. * Bob: Recommends the
referenced Honda paper. * Brian: Despite problem in reliability, can we define
the problem in a way that makes it tractible. Maybe focus on what doesn't get
changed or cause trouble. * Aaron F: would be useful if "happy eyeballs"
protocols tracked failures report so it can be collected and reported out (with
appropriate privatization of data). We need more data on how often things are
done in practice. Stack vendors and browser vendors could do this. Agreeing on
methodologies and data would give some commonality and make it easier to
compare. * Dan: no way to reliably categorize since different per vendor and
behave different when say under attack vs not, etc.  Also 0.2% globally may be
100% in some location like Switzerland. Middleboxes do lots of things, with
dynamic behaviors even for a single connection. On board with happy eyeballs. *
Aaron F: Maybe happy eyeballs should report unhappiness to server. Summary:
observing data on what you normally do.  Testing per se may not be reliable but
stats on how things actually work is useful. * David B: three pieces : a)
taxonomy of what boxes do, b) how to do runtime detection, c) survey of what's

* Christian: Such classification has failed in the past.
* Martin: RFC3489 ... the classification in the spec was a failure ... too
limited. Example of how classification is difficult. * Costin: NATs are the
simplest. If they are trouble, then other are even worse. Who is the
classification targeted at. * Christian: Gave example of behavior you can't
learn from reading docs. * Eliot: +1 for identifying the purpose of the
taxonomy. Thinks it should focus on how to make stuff work. * Mirja: Purpose is
to identify known behaviors and to call out ones that should not be done. *
Jana: Taxonomy's value is time limited. * Erik: What Dan said indicates that
the tracing model will be very unreliable. Maybe it's doable just to come up
with a way to find MBs in the path. * Christian: Maybe classify according to
purpose instead of observed behavior. Maybe useful to have a "bug database" of
"this app doesn't work through that middlebox".  May also be useful to look at
what functions middleboxes do that could be moved to end systems. * Phillip:
Classification makes sense, even if we don't know what data will be useful for.
* Mirja: Would it be useful to have a document that says what things are good
and bad for middleboxes to do? * Bob: Classification is useful to impose
requirements on hardware for purchasers but not possible to get agreement on
anything if all constituencies represented so doc would be empty. * Ted: Where
something is in the path tells you something about who is acting. MB could lie
with it's behavior, but knowing something is being done can still be helpful.
Ability to drive MB behavior based on classification will be very difficult.

any api about middlebox or path behavior would necessarily have to be far
simpler than what they actually do.   And trusting it may be an issue.

* Costin: MB is usually in the first AS hop, at least the ones we care about.
* Erik: Do we have data to substantiate the "first hop AS" claim? It might only
be true in specific parts of the world. Also, re: location, maybe only useful
to identify who's domain of control. * Brian: Referenced a paper about ECN that
indicated that most of the time it was broken due to server side MB, not
usually in the middle.

Ted's slides (move to NFV)
- service chaining where middlebox functions move to virtualized service
functions that can scale out.
        - May cause variability.
        - Need to decide whether VFs can be part of the host stack, whether use
        ECN, etc.
- VFs might be updated more frequently (good) but might start doing (bad)
things one wouldn't do if you had to deploy a hardware box.

* Bob: In general, the point of NFV is to give flexibility in management, so it
should usually give good results rather than bad. * David: Network function
already splitting out to client and client function already being split out to
network. Hope that we don't have to relearn lessons from ECN. * Erik: Asked
about which queues Ted was describing. * Ted: NFV may add hardware Q or
software Q or both. * Erik: Some network functions are packet oriented and some
are connection oriented. Connection oriented may add more delay. * Ted:
Signaling about this could be useful. * Jana: Already flow handling on MBs in
the cloud are shifting flows between queues. Is there more we might want to do
to stabilize? * Ted: Such a use case may want to know more about the flow than
just the path (e.g. trust domains for all the actors). This is probably session
management rather than flow. Also, service chaining happens in multiple trust
domains. Important for path characterization but difficult due to lack of
signaling, whenever you have encrypted traffic.  E.g. middlebox claims to
transcode but needs to decrypt and reencrypt to do so, endpoint should decide
whether it wants to allow based on trust domain. *Lars: Doesn't want to see
network function get split to the client. We've been trying to move SPs in the
other direction. * Ted: Yes there are downsides, but there are also positive
elements of this. * Bob: There are already vendors doing this, though. Gave
some examples. * Aaron: taxonomy needs to include endhost virtual middleboxes

Szilveszter's slides (mobile broadband)
- middlebox layer between IP and transport protocol, for flow identification
and flow start/stop signaling

* Lars: how many bytes would you sacrifice and add to every packet? Concerns
about impact on MSS due to overhead. * Dan: Ongoing efforts with little uptake
so far to allow network to give feedback on path characteristics to clients.

- if we solved middlebox roles of "Policy Decision Point", "providing info
about path" and "sending advisory msgs to apps" that would be sufficient
(leaving out transport protocol performance enhancement, and app layer

* Christian: How many such boxes on the path? And how to handle trust? what if
path has multiple of them, does information increase exponentially and is it
secure?  Can be easily abused for DoS attacks, like happens in MTU discovery? *
Szilveszter: Around 10, maybe? And yes, needs to have trust with all. * David:
Advisory msgs seem to be at layer 2. That needs to be resolved. * Jana: Also
not convinced that pushing layer 2 info up to higher layers is a good idea. *
Mirja: Pulling stats from the monitoring is on the list for tomorrow. So it
detection of MBs. * Richard: Lets focus on monitoring actionable aspects of the
path behavior. * Dan: That's a good thing about using the happy eyeballs data.
* Lars: Can application providers give feedback to the user to get them to put
pressure on providers? maybe need balloons from app to complain about middlebox
behavior.   Referenced Dave's presentation during IETF 68 about what
worked/didn't, but would like quicker feedback to users.

Technical Session 3: Unbreaking transport: lightning talks and discussion
(14:15 - 15:30)

Costin's slides (34-37)
-  middleboxes make Internet unpredictable. Design of mptcp took 5+ years b/c
someone would always stand up and say "there's this middlebox that breaks
that." - There used to be a clean contract, but that's not the case. Contract
is now "I will get the packet there, but beyond that I may do what I wish...",
I being the network. - So apps make very conservative choices to ensure things
don't change in the net. They may not care about privacy, but they want

- Idea for Ninja tunneling (bad cop): Create a multitude of tunnels, that makes
use as wide a use as possible, (UDP, TCP, etc) and stripe it across all of
these channels.  It can work, but can it be efficient? - In steady state, if
you run MPTCP across ALL of these tunnels, the tunnel that is most efficient
will get all the traffic.  If UDP is rate limited, then traffic will spill over
to TCP. - One can be endlessly innovative about the tunnels. Doesn't require
full MPTCP, just apply the CC alg.  Can spread a packet over all tunnels, drop
all but the first one. -  The key point: providers can't kill ALL traffic.

* Brian: how do you ID the packets?
* Costin: for v4, IP ID; for v6, [shrug].
* Aaron:  what happens if the mb is on the server end of the connection?
* Costin: don't consider that a useful application to optimize.  Biggest
problem is first- and second-hop provider deployments. * Miroslav: what about
the efficiency?  If you try a bunch of things you will be wasting resources...
* Costin : in steady state it converges... * Miroslav: but in mobile devices
it's too dynamic. * David Black: Most flows out there are mice, not elephants.
* Miroslav: also this will not work for apps do not get access to net directly.
* Mirja: OS should do it for you. * Costin: are you saying it's difficult to do
in OS? * Miroslav: saying it'll drain resources in a mobile device. * Costin:
no, I open multiple tunnels, use for ALL applications. * Lars: agree with
Costin, try in parallel, faster ones will succeed first. Yes, it wastes
resources, but this is the world we live in. Depends on how often you do the
setup. * Costin: don't think energy consumption is a big deal. * Lars: you
could do some sort of DHT P2P thing: exchange hints about what has happened in
different parts of the network to indicate what tunnels work, what to try
first. * Jana: this is "happy eyeballs" on steroids * Brian: in tunnels * Jana:
curious to see what comes of it. * Aaron: have you looked at using enterprise
VPN services? * Costin: don't think that's a real solution b/c of the rate
limitng story. * D. Black: feels like a remote access VPN solution...

- Good Cop is the constructive approach: API to talk to middleboxes
- Reachability examples: Client can say "I'll let you look at the traffic,
please don't touch it."

* Eliot: think of Dave T's slide about incentives.  You should think about the
various ways to game/abuse this. * Costin: [in the example you gave] cell phone
is already compromised. * D. Black: the point is that "compromise" is not the
end of the attack. * Eliot: it would be useful to use Dave's list as a check. *
Bob: can't see why an ISP would want to do this, as it's a lot of work that is
not tied to a cash flow, doesn't give any immediate benefit.  Getting something
deployed by an operator requires that it be tied to a product. * Costin:  what
about a generic cloud-based service that apps can leverage?  Provider can
charge more, all apps can leverage.

UNbreaking transport slides (lighting talks)
Brian (slide 39)
-"Duelling Approaches": (i) People's front for UDP (ii) TCP libration front

Miraslav (slide 40)
- Redoing everything in UDP will be painful.  We should provide what guidance
we can on how not to do things...

C. Perkins (slide 41):
- Ossification is a good thing.
- TCP is not a research project. As long as the wire format doesn't change, we
can change TCP. - Use of UDP is a good way to evolve thing.  The problem is
that the result is X/UDP, a second class citizen. - How about some signaling to
deploy new things?

David Black (slide 42):
- Scars.  MPLS-in-UDP: IPv6 checksum was problem number; Congestion control was
another problem. - One year later the job is done. It took too much work, took
too long, and the results are not directly reusable. - We need to provide more
guidance.  We could use some reusable designs. UDP encap ought to be easier
than it is.

Felipe Huici (slide 43):
- It took years and years and years for features to come in.  There are
middleboxes everywhere, but maybe that's not the only problem.  It takes way
too long to get even small features into the kernel. - We need to shift
development to the user level.  The result: Multistack.

Michael Welzl (slide 46):
- Keep using happy eyeballs.  Keep introducing new features.

Philip Schmidt (slides 47-49):
- Let applications tell the O/S what they know so that the O/S can take more
responsibility - Can we use similar things to indicate network access load? -
What signaling would be useful for the network to signal back to the host? 
Maybe shift backups to later?

Bob Briscoe (slides 21, 50-53):
- Figure from Honda paper, regarding amount of option stripping/dropping of
unknown options: Home networks were NOT stripping unknown options (small sample
size, though).  Cellular was the worst.  Universities, enterprises, and WiFi
hot spots were blocking  a good percentage ports that were not 443. - TCP
Option "space" - shows how it is easy to exceed 40 bytes. - Main point of pos'n
paper: extend layer X in layer X+1. - In the case described, do it inside the
TCP payload.  But also gives you the ability to extend IP behind a UDP. - Inner
Space: option in payload. This will go through a middlebox that resegments. - A
more structured way of doing HTTP2.

Brian (Channelling Stuart Cheshire, slides 44/45)
- You design your own transport because TCP doesn't work.
- But then your own hasthe same performance issues, but since you don't want to
have wasted six months, you ship your broken solution anyway. - as Brian: there
are a lot of corner cases in TCP-as-deployed, lots of stuff in sysadmin
literature about "why tcp sucks" There are CDNs that are pushing the IW up to
75 packets.

* Jana, channeling Stuart ;-): UDP is not a !@$#@#$!$!@# transport protocol - I
hate that we call UDP a "transport protocol". 8-page protocol written in 1970.
It's a demux protocol, that's all. * Christian: UDP just gives IP service to
application.  It's just a filter.  It's "raw sockets for apps". * Colin: it's
viewed as a kludge... "tunnel over UDP is a second class kludge." Goal is not
to get rid of UDP but to give guidance on how to do things right. * Jana:
Things running atop UDP are 1st class protocols.  UDP is an encap. * Christian:
HTTPS is a kludge. * Miraslav: There is no single TCP that we can refer to, to
be able to claim something bad about it.  If we relax TCP semantics and API,
then we end up with UDP. * Spencer: how much longer should we have to wait for
DCCP to come back? One of the big issues of the MPLS/UDP draft was that there
was no indication of loss. * Brian: haven't been very good at standardizing
cong ctl protocols. * Aaron: DCCP published a bunch of those. Having TCP in the
kernel has limited risk of screwing up congestion control.  Not everyone has
the resources of Google or Microsoft to devote to this.  Permissionless
innovation at this layer may lead to places we don't want to go. * Dave Thaler:
(privacy) the practical limitation is that you can only support so many IP
addresses in h/w.  There are practical limitations. * Jana: likes the the idea
of moving things up the stack. It all works.  We can't stop it from happening.
* Colin Perkins: the IETF is really good at standardizing congestion control,
but not very good at getting them use. * Christian: I am a congestion control
heretic. I do not believe that congestion control is something that should be
done in the end point. I'm not a fan of putting function in the network, but if
it's there I can defend users. The stability of the Internet should not depend
on who implements what stack. * Bob Briscoe: but that's how the Internet works:
all the users are divided up. In Felipe's position paper, the other side is to
deploy stacks on middleboxes.  Mostly what we want to do is remove middlebox
behaviors, not add them. Adding another one won't make it any safer. * Gorry:
we kept talking about transport as if it were congestion control, but there are
a whole bunch of functions that need to be shared, hard if they are in user
space. * Joe: why are people who write code in the kernel are more trustworthy
than those who write applications? * Lars: no one would say app-writers are
untrustworthy.  Problem is it's easier to deploy something in app-level, if you
get it wrong, consequences are bad.  Same is true for encryption and cc. *
Mirja: the idea is to change the bits that you feel the need to change.  Maybe
retain the bits you don't want to change. * Lars: pluggable CC framework in
linux and BSD has a very different framework than you are talking about. It's
tied to how TCP works. Don't underestimate the API difficulties * Mirja: People
will implement their own stuff over UDP; with or without kernel support * Ted
Hardie:  I have good news:  CC is not your biggest problem! WebRTC requires
browser to act like a router would act. They're trying to do application
appropriate resource drain so as not to step on their own earlobes. By the time
you get to IP, it's not a single flow. Moreover, this will spread:  WebRTC
already did the hard part, other things will come along and do similar. 
Processing is exploding in both directions:  into the network with NFV, into
the app/browser.  Lots of adaptive radiation in both directions. If the
Internet as a ecology can't handle this level of variability, maybe something
else in the network is wrong.  We have to make the network resilient to it, and
in the best possible case expose APIs for it... * Philipp: now I regret
skipping my second slide about how to implement socket intents... didn't go
into the kernel for the prototype. If you want to build a new application, it's
really hard to do all the stuff.  Modern browser: not sure if it's an OS or an
extension of the OS, or what. * Aaron: disagree with Ted.  Congestion is about
protecting me from you.  Christian's proposal makes my brain hurt.  What is the
ISP's idea of my fair share? * Jana: Just to answer this point...N/w is not the
only thing to do CC, but it's certainly doing rate-limiting.  Only disagree
that cc is hard to do, but it needs to been done by people who know how to do
it. Independent of kernel or user space.  Can be done in user space. Come to
ICCRG. * Aaron: If you screw up CC, I suffer.  People punished are not
necessarily the users of the programmers' apps. * David: we're using the term
"congestion control" as a fairly wide space.  At one end of the spectrum, there
is are specific algorithms: CUBIC, Vegas, ...  In between, we have the AIMD vs.
TFRC.  Some of this can be rather harmful to real networks.  At the far end of
the spectrum we've adopted "circuit breakers"for situations where s/t is
clearly wrong and s/t needs to be done about it. These circuit breakers might
be more important as we go permissionless. * Erik: following up with Ted about
putting all internet functionality in the application.  It is equivalent now to
a router: muxing on both upper and lower i/fs.  This is richer than what we
talked about before. I assume, Ted, you would send different packets out
different ports.. * Ted: yes, and some will go through TURN boxes, some not,...
routing protocol picks the "next hop" for the message that's going to a
specific destination. * Erik: so CC runs where? * Ted: Congestion control is
handled differently for different output ports to the extent that different
ports are in different contexts. * Erik: So if app developers can get that
right, CC is easy? * Ted: These things can misbehave the way routers can
misbehave. Challenge where the O/S is handling TCP and app is handling UDP, and
there is this mismatch. Oddity: they are doing all this stuff, but some of it
is actually going out over TCP to the web server, being controlled by a
differnet part of the stack!  So they may interfere. NOT trying to say CC isn't
important.  We've already handed ability to shape traffic at a sub-5-tuple
level to the browser "stack".  There is much more complexity here.  Bad news:
they way sandbox tabs work now is, they are a hypervisor for a set of VMs. *
Eliot: "Ted, you're a hard act to follow".  Go back to David's comment about
the "gentlemen's agreement".  CH's proposal also made my brain hurt.  Question
for tomorrow: where is the endpoint-network line? What work needs to be done in
terms of the host, and the network? * Christian: don't get me wrong, I will try
to do the right thing, but ultimately the enforcement has to be in the network.
* Eliot:If we are working under the assumption that there is a gentleman's
agreement where there is none, the network is a backstop to prevent that. *
Lars: User space stuff is good where there isn't competition on the device. But
for general purpose libraries? * Aaron: careful about separating building
things atop UDP and in user space. building on top of UDP != building in User
space. User space is about speed of deployment, UDP is about pervasiveness. *
Joe H: Agree.  Other thing user space allows is to try out some new things,
without having to devote as many cycles to get to running code.  But there may
be efficiencies to sharing, putting in kernel. So, e.g., can start thinking of
kernel as another node in the network. * Jana: agree with Aaron's distinction. 
What's difficult and easy to implement depends on where you work.  Filter
becomes what you control. User/kernel distinction kind of depends on context
(e.g., mobiles it's different).  Android, iOS have different ... If you want
fast deployment, you need s/t outside OS. * David B.: when you move parts of
stack into user space, it gets more interesting and less predictable. 
Sometimes it matters, sometimes it doesn't.  If you want to move the whole
stack, it gets really interesting when the OS is there to help mux resources
under you when you didn't expect it. * Erik: (on inner space) if we have
middleboxes with various DPI things (e.g., .XML => run through XML parser),
moving part of the TCP header into payload will fail. * Bob: there's an option
to get through one of those boxes, that puts dummy http headers.. This is not
trying to get through security checks, ... * Erik: are you saying you can
detect mbs on the first segment? * Bob: no, URL filters just parse as far as
they need to... you need to encrypt to protect... * Jana: like inner space
proposal a lot because it makes TCP the substrate. You're going to have to do
work, but this gets you past some middleboxes. * Bob: Right.  Designed for
middlebox operators, another thing: framing of TCP payload could be offloaded
to an outboard function...

* Jana (channelling Stewart talking to Brian as Stewart...): here's a common
application design pattern. App developers don't understand what the problem
really is, and will go ahead and blame TCP without investigating.  Common
pattern is blame TCP, (try to) fix it in a brand new protocol, fail because you
didn't really know where the problem was. We need to spend time teaching people
how to use TCP. Plus writing your own thing leaves you without tools to debug.
* Brian: another whole topic: how do you tool for debugging?


* Brian: "Now we have to figure out what we just said..."
* Mirja: We didn't address the service composition question [TAPS] at all.  Is
this something that's not interesting b/c it's already addressed by taps?  or
did we not have the right slides? * Joe: what's it look like to the app
developer is more important than how to talk to the kernel...  Maybe a subset
of people can hash that out. * Brian: that seems more like the 4th TAPS
deliverable after the recharter... is the expanded transport API and the path
characteristics API separable? * Dave T: separable to some extent, can imagine
layering them (path API lower).  One-way dependency. * Gorry: separable but
both really, really useful. * Dave B: +1 * Ted Hardie: in a world where these
are separable, where you are talking to the path outside the transport, you
rapidly make it un-useful for most application work, b/c they add too much
latency. But if you get backscatter as it goes along (i.e., via unifying them)
you get a significant benefit in latency - at a considerable cost in
complexity. * Joe: set of events, from different layers, some in kernel, some
not. Might chain in interesting ways. * Aaron: sounded like what Ted said was
compatible with what Dave T said - you could stack these on top of each other.
Unified transport could have two APIs at differnet levels, one on top of the
other. * Ted: agree * Colin: to what extent is the path discovery a feature? 
Is it part of the path discovery...

- Topics for the second day:
        (i) Inline middlebox measurement.
        (ii) Work to be done around guidelines, enablement, etc. for user-space
        stacks.  How exposed to apps, how to do permissionless innovation
        without breaking the Internet. (iii) Path characteristics API - Think
        in terms of events you can
send/receive: start, end session, get path char (see iv).
        (iv) Path characteristics protocol (SPUD?) [middlebox layer]

* Joe: one possible incarnation is over UDP to get info to/from path via a
separate channel.  Session protocol, used to start/stop sessions that mbs could
use it.  (Includes failure reports in happy eyeballs.)

        (v) Trust domains - because the problem isn't hard enough.
        (vi) UDP design guides. [Note: differs from user-space stacks.] ("UDP
        for dummies")

* Aaron: that would be a great topic for an IETF BOF.
* Bob: would like to know how many people agree with Christian's point that we
are not going to make any progress until we change the balance of power... 
COuld talk about what a working group would look like in that space... a number
of hings we could look at without protocol design. * CH: many aspects: what are
the roles of DTLS, TCPINC, ... * Joe H: I was thinking about that in terms of
reqs.  That might be a separate path.  For people who don't believe UDP is the
way to go, maybe talk about TPC implemetnations... * CH: if you think CC is
hard, re-doing TLS is really hard...need a common layer... * Spencer: Aaron
pitched a thing about a non-WG BOF.  BOF request date is next Friday. * Brian:
so we have time!