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

On Jul 26, 2013, at 1:27 AM, mohamed.boucadair@orange.com wrote:

> 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.

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:
> 
> * 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.

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

-d

> 
> Cheers,
> Med  
> 
>> -----Message d'origine-----
>> De : pcp-bounces@ietf.org [mailto:pcp-bounces@ietf.org] De la part de Dan
>> Wing
>> Envoyé : vendredi 26 juillet 2013 00:44
>> À : pcp@ietf.org
>> 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.
>> 
>> 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
>> 
>> 
>> _______________________________________________
>> pcp mailing list
>> pcp@ietf.org
>> https://www.ietf.org/mailman/listinfo/pcp