Breaking up the Transport Logjam
===============

- new congestion control algorithms are undeployable 
- Paper claim: transport layer is stuck in its evolutionary path
- solution: separate different functionalities into 3 layers
	-- transport layer: application related stuff, e.g., reliability
	-- flow layer: flow performance regulation, e.g., congestion control
	-- endpoit layer: endpoit namting, e.g., info about ports


Q: there have been earlier designs to separate these functionalities such as 
source/destination addresses. why they were abandoned?
A: do not know why but worth finding out

Q: specific question about TCP: how TCP should be changed to make it suitable for the
proposed architecture?
A: protocol detail is the future work

Q: how to deal with two 16 bits endpoits compared to a 32 bits one. 
does this architecture help?
A: yes

Q: are you proposing hop-by-hop congestion control?
A: no, this goes beyond that. in extreme scenario it is hop-by-hop.


===========================================================================

Reducing Transient Disconnectivity using Anomaly-Cognizant Forwarding

- BGP convergence is a major cause of disconnectivity
- proposed Solution: anomaly-cognizant forwarding
	-- accept routing anomalies as a fact and protect end-to-end delivery 
	by detecting and recovering from anomalies
- a few examples showing how ACF works in some scenarios
- ACF does not use pre-computed failover paths and paths are not assumed to be stable
and anomaly-free
- evaluation based on simulations
- deployment: it needs to modify the core IP routing


Q: what is the cost of computing a new path when a packet comes from a blackList AS?
A: there is some cost and needs to be considered.

Q: there is a 2-3 year old paper on a similar topic by ??
A: have not seen that.

Q: what guarantees are provided?
A: this is more ad hoc, do not provide guarantees, maybe some probabilistic guarantee
can be obtained

Q: in recovery mode, how do you get to tire-1 ISP?
A:? 



Session 6: Pathlet Routing

As a source of the packet, it knows the content of the packet as well
as the QoS (e.g. bandwidth and latency) requirements.  The source has
the flexibility to choose reliable paths among multiple end-to-end
paths.  However, such multipath routing is not deployed in reality,
mainly due to the very limited inter-domain routes governed by BGP.
The goal of this paper is to provide flexible policy control to enable
and offer the services for multipath, by combine the benefits of both
BGP and AS-level source routing.  This work introduces the notion of
pathlet, which encompasses a series of virtual nodes (Vnode).  Each
Vnode can be defined to represent an end-host, an ingress point of a
BGP network, or a fragment of physical route, depending on the QoS and
routing requirements.  The pathlet is advertised to the network in a
gossip fashion.  The pathlet is also included in the packet, and is
updated as the packet traveling through the network.  The authors
demonstrated that this algorithm can be applied to emulate many
protocols (e.g., BGP and MIRO), and Local Transit policies.

Dicussions:  Pathlet routing allows network designers to separate BGP
inter-domain and intra-domain traffic.  Since Pathlet works with
Vnode, and the Vnode can represent network nodes any level of
abstraction, the routing can be done on the AS level and can also be
carried further to the end-host level.