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

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

>-----Message d'origine-----
>De : Dan Wing [mailto:dwing@cisco.com]
>Envoyé : vendredi 26 juillet 2013 22:23
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : pcp@ietf.org
>Objet : 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