[Sdnp] Proposed SDN BOF charter
shane at castlepoint.net
Tue Sep 20 11:40:07 EDT 2011
Just catching up ...
On Sep 19, 2011, at 1:55 PM, Robert Raszuk wrote:
> Why don't we instead of exposing network parameters to applications do the opposite ... make network application aware ? Today networks just transport packets. They have no clue on what they carry in those packets.
Actually, that's not true ... see: DiffServ.
> What if the goal of this WG would instead read: "Making Networks Applications Aware"
> Today operationally we could do RSVP Intserv (as Ed very correctly pointed out). With some recent enhancements we have provided tools to operators to do the thinking and construct mostly intra-domain TE paths centrally to engineer the flows. This does not work inter-domain when we are to talk across continents or globe. This also is all about control plane reservations therefor any unaccounted flow in the network messes up the picture.
> My vision is to give network a packet and let the network transport it not only like today by dry SPF or BGP best path rules, but taking into the forwarding decision the nature/type of such packet.
> That means effectively three things:
> - define a very small set of application primitives which must be handled by the network (delay, link affinity, jitter, loss, bandwith, protection etc ...)
> - extend current network protocols to measure and use in their decision above primitives
> - define (or perhaps share with existing work in other similar bodies example ONF) the way to communicate the primitives to the network (per packet, per flow, per src application etc ..)
All of this has already been defined by DiffServ, which is being used by lots of carriers for their various VPN offerings. Now, that said, DiffServ is [very] static in today's deployments. I explicitly configure each node in a network to classify, put into a queue and schedule packets _statelessly_ according to a pre-defined forwarding treatment policy. The problem is DiffServ does not dynamically adapt, unless I specifically go back and reconfigure each network element with a new forwarding treatment (schedulers, etc.) for packets. (That's the trade-off we accepted when DiffServ was created in order to have a stateless CoS mechanism. IOW, it is what it is, let's not "fix" it).
Because DSCP is statically configured in the network, there is an increased burden in OpEx because you have to monitor & Capacity Plan not only raw BW, but also per-CoS (per-DSCP) scheduling treatments at each hop in the network. (Think of how many devices and, more importantly, how many links there are in very large Core & Access networks today). This is most likely why [I suspect] a lot of carriers do not deploy even very simple/straightforward scheduling treatments within the Core of their network, (it's too hard to monitor & maintain). So, even DSCP isn't a panacea. And, quite frankly I'm fairly sure that application developers have no clue what the different forwarding treatments: a) exist; or, b) what, if any, meaningful differentiation they would/could provide to forwarding of their traffic, so they just don't use them.
Ultimately, the above speaks directly to why there's a need for something like SDNP. Most/All developers really don't want to care about the fine-grained details of what happens _within_ the network ... they just want their apps to either "just work" and/or to interrogate the network to _know_ whether their apps will "just work". How those instructions get carried out inside the data-plane of the network are up to the SDNP conductor and it's translation toward various plug-ins to carry that out.
> - make the networks smarter to carry today and tomorrow apps,
> - completely distribute the smartness,
> - supporting small set of primitives would be easy to agree inter-
> vendor or inter-provider,
> - good scaling property,
> - drastic shift from today's "full manual operator control" how his
> bits are flowing in entire network or in subset of the network
> allowed for being applications aware.
> While this is just a very short note I welcome your comments, questions, flames to the sort of fully reversed out of the box approach as compared with the just proposed charter.
> SDNP mailing list
> SDNP at lucidvision.com
More information about the SDNP