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

From: Dan Wing <[email-masked]>
Date: Thu, 25 Jul 2013 15:43:33 -0700

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 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 per-user or per-device or per-application.

Details are in http://tools.ietf.org/html/draft-wing-pcp-flowdata.

Comments welcome.
-d

---

From: <[email-masked]>
Date: Fri, 26 Jul 2013 10:27:45 +0200

Hi Dan,

This is indeed an interesting piece of work...which has also its drawbacks;-) See the comment I made about the generic framework here: http://www.ietf.org/mail-archive/web/int-area/current/msg03627.html.

Targeting a perfect solution which does not suffer from limitations is not viable IMHO. This is why I'm seeing this work as a useful tool to be added to the existing toolkit. This work opens a new perspective which is worth to be considered by the WG. In addition to the flowdata work, I'm also suggesting to consider other work items such as:

* Use PCP to enforce DSCP remarking policies (http://tools.ietf.org/html/draft-boucadair-pcp-extensions-03#section-3). This is useful when the PCP Client is operated by the provider. This is an intra-domain case.
* Use PCP to discover the DSCP marking to be used for outbound packets: this option can be used with or without FLOWDATA option. The typical use case is where the PCP client is embedded in a CPE (not the host) and various marking policies are used at the access network. This is an intra-domain case.
 
Cheers,
Med  

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De la part de Dan
>Wing
>Envoyé : vendredi 26 juillet 2013 00:44
>À : [email-masked]
>Objet : [pcp] differentiating traffic, draft-wing-pcp-flowdata
>
>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.
>
>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.
>
>  * 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 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 per-user or per-device or per-application.
>
>_______________________________________________
>pcp mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pcp

---

From: Dan Wing <[email-masked]>
Date: Fri, 26 Jul 2013 13:23:15 -0700

> This is indeed an interesting piece of work...which has also its drawbacks;-) See the comment I made about the generic framework here: http://www.ietf.org/mail-archive/web/int-area/current/msg03627…

I am not involved with the generic framework.  But reading your objections in that post, the primary objection seemed to be application developers won't signal their flow characteristics.  To do such signaling, such signaling would need to provide value to the application developer or to the end user experience.  That is, to do such signaling, the signaling has to solve a real problem.

I believe multiple flows contending for access bandwidth is a real problem.

If it is not a problem (that is, sufficient bandwidth is always available), then I agree there is no value or purpose in differentiating flows over that network.  However, every year that I hear someone proclaim "we have enough resources", that has only been true for a year or two -- no matter if the resources are CPU cores, memory, bandwidth, network latency, or disk space.

> Targeting a perfect solution which does not suffer from limitations is not viable IMHO. This is why I'm seeing this work as a useful tool to be added to the existing toolkit. This work opens a new perspective which is worth to be considered by the WG.

Thanks for your positive feedback.

> In addition to the flowdata work, I'm also suggesting to consider other work items such as:
> 

Signaling DSCP is not something described in draft-wing-pcp-flowdata -- on purpose.

-d

---

From: <[email-masked]>
Date: Mon, 29 Jul 2013 11:28:05 +0200

Hi Dan,

For the DSCP case, please not I'm referring to intra-domain cases not inter-domain ones. The cases I have in mind does not require the involvement of the end host, but the following:

* a PCP client under the responsibility of the service provider.
* a managed CPE

DSCP value re-setting and OSSifying dscp setting are not issues for those cases. 

I will re-spin the dscp pcp option to further clarify the usage.

Cheers,
Med

>De : Dan Wing [mailto:[email-masked]]
>Envoyé : vendredi 26 juillet 2013 22:23
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : [email-masked]
>Objet : Re: [pcp] differentiating traffic, draft-wing-pcp-flowdata
>
>
>> This is indeed an interesting piece of work...which has also its
>drawbacks;-) See the comment I made about the generic framework here:
>http://www.ietf.org/mail-archive/web/int-area/current/msg03627.html.
>
>I am not involved with the generic framework.  But reading your objections
>in that post, the primary objection seemed to be application developers
>won't signal their flow characteristics.  To do such signaling, such
>signaling would need to provide value to the application developer or to
>the end user experience.  That is, to do such signaling, the signaling has
>to solve a real problem.
>
>If it is not a problem (that is, sufficient bandwidth is always available),
>then I agree there is no value or purpose in differentiating flows over
>that network.  However, every year that I hear someone proclaim "we have
>enough resources", that has only been true for a year or two -- no matter
>if the resources are CPU cores, memory, bandwidth, network latency, or disk
>space.
>
>> Targeting a perfect solution which does not suffer from limitations is
>not viable IMHO. This is why I'm seeing this work as a useful tool to be
>added to the existing toolkit. This work opens a new perspective which is
>worth to be considered by the WG.
>
>> * Use PCP to enforce DSCP remarking policies
>(http://tools.ietf.org/html/draft-boucadair-pcp-extensions-03#section-3).
>This is useful when the PCP Client is operated by the provider. This is an
>intra-domain case.
>> * Use PCP to discover the DSCP marking to be used for outbound packets:
>this option can be used with or without FLOWDATA option. The typical use
>case is where the PCP client is embedded in a CPE (not the host) and
>various marking policies are used at the access network. This is an intra-
>domain case.
>
>>> I hope the problem described above resonates with people on this list.
>If
>>> so, read on.
>>>
>>>