Subject: [tsvwg] differentiating traffic, draft-wing-pcp-flowdata

From: Dan Wing <[email-masked]>
Date: Tue, 3 Sep 2013 14:57:51 -0700

I was encouraged to post this to TSVWG because this activity overlaps considerably with previous TSVWG and Transport-y activities such as DSCP, RSVP, NSIS, and more.  The following post was made earlier to the PCP mailing list [1] but I doubt many folks from TSVWG read it or are aware of the proposal in PCP.

Comments welcome.

Many networks have insufficient access bandwidth and it is desirable to handle flows differently over that access link based on the flow's needs (high bandwidth, low loss, high delay) or if the flow is to a certain device or certain user (living room television, tablet, mom/dad/kid).  Hosts don't have a way to prioritize flows downstream (towards the host) and have poor capability to prioritize flows upstream, especially among the various hosts on the network.  Various solutions to this problem have been developed over the years (DSCP, RSVP, NSIS) but have drawbacks.

I hope the problem described above resonates with people on this list.  If so, read on.

In draft-wing-pcp-flowdata we propose a solution:  the host describes the flow characteristics to the network and the network indicates its (in)ability to accommodate the flow.  That flow description can be used by the default network, or propagated along the network.  For example in a home network the flow description can propagate from in-home CPE router to the ISP's access router, and in an enterprise network the flow description can propagate within the enterprise network and up to the ISP's access router.  When the flow characteristics are communicated to both sides of a resource-constrained link, the routers on both end can provide different packet forwarding treatment to the flow.

The mechanism draft-wing-pcp-flowdata brings some advantages:

 * incrementally deployable.  This can be implemented entirely within a subscriber's network without participation of their ISP, providing some value (but of course not as much value as being deployed by the ISP's access router).  Similarly, this can be implemented on the ISP's router and the host could signal directly to that ISP's router without needing support of the intermediate network.
 * adaptive bit rate applications can improve their user experience by avoiding attempts to exceed the network's upper bandwidth limit
 * traffic differentiation can be per-"event" (e.g., streaming TV of the Olympics, VoIP call with an important customer), in addition to more traditional differentiation based on user/device/application.

Details are in http://tools.ietf.org/html/draft-wing-pcp-flowdata and the presentation I made to PCP at IETF87, http://www.ietf.org/proceedings/87/slides/slides-87-pcp-5.pdf

-d

[1] http://www.ietf.org/mail-archive/web/pcp/current/msg03216.html

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 14 Sep 2013 08:28:20 +1200

Hi Dan,

On 04/09/2013 09:57, Dan Wing wrote:

...

> In draft-wing-pcp-flowdata we propose a solution:  the host
> describes the flow characteristics to the network and the
> network indicates its (in)ability to accommodate the flow.
> That flow description can be used by the default network, or
> propagated along the network.  For example in a home network
> the flow description can propagate from in-home CPE router to
> the ISP's access router, and in an enterprise network the
> flow description can propagate within the enterprise network
> and up to the ISP's access router.  When the flow
> characteristics are communicated to both sides of a
> resource-constrained link, the routers on both end can
> provide different packet forwarding treatment to the flow.

Well, I sort of understand the words, but the mechanism seems to
rely on some magic.

The app tells the PCP server what it wants. But that in itself
achieves nothing. If there are routers between the host and the
access router, how do they play (unless a mechanism such as
diffserv is used)? How do the routers upstream from the access
router play (unless a mechanism such as diffserv is used)?

I can see this as a new mechanism for dynamically requesting a
specific QoS treatment for a flow. I can't see it as a mechanism
for satisfying the request. What am I missing?

    Brian

---

From: Dan Wing <[email-masked]>
Date: Sat, 14 Sep 2013 11:08:42 -0700

> router play (unless a mechanism such as diffserv is used)?

Per-flow state could be installed on such routers using SDN or SDN-like techniques.  For example, the PCP message could be proxied to the on-path routers, or the PCP message could be converted to an SDN message (SNMP, Openflow, whatever makes sense on that network).  The host using draft-wing-pcp-flowdata doesn't care how the other routers are configured, and that communication is outside the scope of draft-wing-pcp-flowdata.

> for satisfying the request. What am I missing?

The request is satisfied by the network installing per-flow state.  The scope of the solution is the access network where we suffer most from limited access bandwidth.

-d

---

From: Scott Brim <[email-masked]>
Date: Sun, 15 Sep 2013 12:51:48 -0400

On Sat, Sep 14, 2013 at 2:08 PM, Dan Wing <[email-masked]> wrote:

> Per-flow state could be installed on such routers using SDN or SDN-like
> techniques.  For example, the PCP message could be proxied to the on-path
> routers, or the PCP message could be converted to an SDN message (SNMP,
> Openflow, whatever makes sense on that network).

Why go to all that trouble?  We have several path-coupled protocols for
doing this sort of thing already.  This is also what NUTSS and the EME RG
did, at a policy level and backwards (although not in high heels).  And you
could do it with LISP.  SDN?

Scott

---

From: Dan Wing <[email-masked]>
Date: Wed, 25 Sep 2013 11:53:51 -0700

On Sep 15, 2013, at 9:51 AM, Scott Brim <[email-masked]> wrote:

> Per-flow state could be installed on such routers using SDN or SDN-like techniques.  For example, the PCP message could be proxied to the on-path routers, or the PCP message could be converted to an SDN message (SNMP, Openflow, whatever makes sense on that network).  
> 
> Why go to all that trouble?  We have several path-coupled protocols for doing this sort of thing already.  This is also what NUTSS and the EME RG did, at a policy level and backwards (although not in high heels).  And you could do it with LISP.  SDN?

EME (and Paul Francis' NUTSS proposal which created EME) did not gain traction and EME was dissolved.  We could analyze why, but more interesting to me is that draft-wing-pcp-flowdata could succeed because it uses an underlying protocol (PCP) that is closely related to an already-successful protocol (NAT-PMP).

The draft-wing-pcp-flowdata proposal is an SDN technique -- it programs the network elements, and yes it could influence LISP tunnels.

-d