Evolving Network Protocols

Q.	Is it easy or hard to change Internet protocols today?
A.	Quite difficult.  End-systems get upgraded quite infrequently.  7.5% of computers 
today still run Windows 95/98/NT!  Upgrading routers involves a multi-step process: 
convincing router vendors to implement it and convincing ISPs to deploy it.  
Sometimes, ISPs may really want a new feature in which case there is enough 
motivation for vendors to implement it.  But not necessarily.

Q.	What is harder: end-system protocol upgrades or in-network upgrades?
A.	It depends.  Upgrading a single end-system is easy.  But upgrading the entire 
population is substantially harder.  How much should backward compatibility matter?  
Upgrading a single enterprise network can be straightforward.  But, coordinated 
upgrades across ISPs are a lot harder.  Imagine having to upgrade BGP.

Q.	What examples of successful protocol evolution can you name?
A.	DNS, TCP congestion control, cellular phone networks

Q.	Overlay networks to the rescue.
	Application-layer multicast, RON, CDNs, …

Q.	Why are overlays attractive?
	Deploying new network services is hard: standards, upgrade inertia
	Get the service provider out of the loop: makes deployment “trivial”

Q.	What is i3?
A.	Rendezvous/forwarding service

Q.	Strengths of i3
A.	Decouples addressing from routing.  Other examples are the Intentional Naming 
System.

Q.	Is i3 trivial to deploy?
A.	Benefits only when sufficient people switch over to it.  Who will control and manage 
(and pay for) the infrastructure?

Q.	Is route stretch is significant problem?
A.	If the app-specific processing dominates, then no.  But it does introduce additional 
dependencies.  You now have a dependency on a piece of infrastructure that may be 
outside your organizational control.

Q.	How much does i3 help with protocol evolution?
A.	Not clear.  Every time they need a new functionality, they add more features to the i3 
suite.  Need more experience to figure out whether the i3 design is flexible enough.  
Not clear that it is in fact the right approach.  Many security issues that are glossed 
over in the paper (e.g., will this now need a PKI?  What about exposing the shared id 
for multicast transmissions)

	Many of their solutions seem like force-fits.  Overlay-multicast is already inefficient.  
Their solution just seems like kludge after kludge.

Q.	Overlays can cause problems.
A.	Violate SLAs.  Traffic engineering becomes harder.  Churn can result in excessive 
management traffic and overhead.

Q.	Should network providers care?
A.	Providing just connectivity is a losing proposition.  Overlays enable new services ==> 
potential for more $$$.  Improved performance, reduced traffic in core ==> potential 
for saving $$$.

Q.	Are overlays the real thing or simply a transitional/experimental deployment 
framework?
A.	Depends on the application.  CDNs are clearly overlay applications.  What about 
PlanetLab?

Q.	Is transport evolution different from network protocol evolution?
A.	In some ways; typically involves only the end-points.  Not always though: e.g. 
improving TCP performance through ECN.

Q.	Explain STP
A.	Protocol implementation in a type-safe language.
	Sandboxing for resource control and safety.
	TCP-friendly rate limiting.

Q.	How much does STP help in transport protocol evolution?
A.	Deploy mobile code to upgrade the other endpoint.  Tons of security issues.  As long 
as you are willing to trust the sandboxing system; can you really?  Software systems 
are notoriously buggy.  Imagine discovering a bug in the subsystem that allows other 
people to run code on your computer!

	Tied to TCP.  Can’t implement protocols that need to be more aggressive than TCP.

	How is deploying STP any simpler than deploying a new transport protocol.  What 
happens when STP 2.0 comes out?