Re: [rtcweb] [rmcat] [tsvwg] Using intelligent dropping to improve video quality under congestion (draft-lai-tsvwg-normalizer-00.txt)

[ken carlberg <[e-mail]>]

Toerless,

sorry for the tardy reply.  I'll dig through my archives and send you a copy.  my draft proposed adding a "classifier" field, but I only did one rev (which was missing some better rationale after a long talk I had with Dave Oran) and i suspect that it would need a fair amount of scrubbing before re-issuing another version.  the first order of business, though, will be to gauge the feedback/comments to your draft.

-ken

ps, CJ thanks for your clarification in your previous response


On Jul 11, 2013, at 8:30 PM, Toerless Eckert <[e-mail]> wrote:

> Thanks, Ken
> 
> Indeed yes, that's exactly the line of thought that we would like to
> see proceed as well. Any URL still existing for that draft ?
> 
> "application layer gateway" could specifically mean switching MCU using
> intelligent dropping in conjunction with outbound congestion control.
> 
> I definitely would like to see RTP headers as the ultimatele marking
> option even for routers to do intelligent dropping (or other packet
> processing "beyond DSCP)). Intra-flow (per-packet) DSCP is just a big pain 
> (aka: impossible) for applications. Many OSs don't have any APIs to support
> this. And DSCP management in networks is already difficult enough as it
> stands.
> 
> Would certainly like to see if there is interest to write up r present
> more pieces of this puzzle, especially an RTP extension. We just felt that the
> fairness in intelligent dropping was the biggest concern our video
> application folks had, that's why we wanted to explain how that piece
> could work first. 
> 
> Cheers
>    Toerless
> 
> 
> On Thu, Jul 11, 2013 at 12:04:58PM -0400, ken carlberg wrote:
>> Toerless,
>> 
>> some food for thought...
>> 
>> about 10 years ago, I put together a draft that added an optional TLV prioritization header to RTP to accomplish something similar in terms of having the app decide which was the better RTP packet to drop during times of congestion.  My aim was to have these decisions made at forwarding application-layer gateways that did not act as a RTP/RTCP endpoint.  The strength of the approach (in my opinion :-) was that it could span pockets of non-diff-serv regions and still carry significance downstream.  The weakness was the need for DPI if one wanted to make a more informed decision along the path about dropping a packet.
>> 
>> I wonder if such a dual-layer design might be helpful in your efforts.  In any case, I have an interest in the normalizer draft.
>> 
>> -ken
>> 
>> 
>> On Jul 10, 2013, at 2:01 PM, Toerless Eckert (eckert) <[e-mail]> wrote:
>> 
>>> When dealing with congestion for real-time datagram (UDP/RTP) based video flows, one idea
>>> that we think has shown to provide good value is to intelligently drop in the network
>>> preferentially the least important packets within a video flow, for example non-referenced
>>> P-frames, because their loss creates the lowest impact to video quality.
>>> 
>>> One of the main concerns raised against such schemes was one of fairness. If flows 
>>> would start to indicate different priorities for packets in them, how would we
>>> be able to avoid that flows would indicate all their packets to be of high priority
>>> to shift packet drops to other flows. Or even more importantly: how could we motivate
>>> flows to indicate that some of their packets are low priority without them having to
>>> fear that they would experience more loss than than flows that don't do this.
>>> 
>>> So, there is one draft that we would like to present (presumably in TSVWG)  explaining
>>> how we think this problem can be solved: draft-lai-tsvwg-normalizer-00.txt
>>> 
>>> (Actually, this is how we did solve the problem in our implementatin of intelligent dropping,
>>> so this is not theoretical).
>>> 
>>> Now granted, the problem of fairness is but one element of building a complete ssytem
>>> around the idea of intelligent dropping, so if folks here on the lists would like to
>>> see for example 
>>> 
>>> a) how well can it work in routers to shift packet drops to low-prio packets
>>> b) whats the evidence that it's good for video quality
>>> c) How should we do the marking best going forward
>>> 
>>> Then please let us know. We'd be very interested to provide insight into the parts of
>>> those pieces that we have also worked out or discuss the ones we have not (primarily c ;-)
>>> 
>>> Thanks!
>>>   Toerless
>>> 
>>> In-Reply-To: <[e-mail]>
>>> 
>>> On Sat, Feb 09, 2013 at 03:00:48AM +0000, Cheng-Jia Lai (chelai) wrote:
>>>> Hi all,
>>>> 
>>>> We have submitted a new Internet draft to describe a Normalization Marker (NM) for DiffServ AF PHB groups, based on our work at Cisco. The goal of NM deployment is to create a new incentive for video encoders to generate more discardable packets when using AF PHB in DIffServ. We are looking forward to your review comments.
>>>> 
>>>> Best regards,
>>>> CJ
>>>> 
>>>> -----Original Message-----
>>>> From: [e-mail] [mailto:[e-mail]] 
>>>> Sent: Friday, February 08, 2013 6:25 PM
>>>> To: Cheng-Jia Lai (chelai)
>>>> Cc: Wenyi Wang (wenywang); Stan Yang (stanyang); Toerless Eckert (eckert); Fred Yip (fyip)
>>>> Subject: New Version Notification for draft-lai-tsvwg-normalizer-00.txt
>>>> 
>>>> 
>>>> A new version of I-D, draft-lai-tsvwg-normalizer-00.txt
>>>> has been successfully submitted by Cheng-Jia Lai and posted to the
>>>> IETF repository.
>>>> 
>>>> Filename:	 draft-lai-tsvwg-normalizer
>>>> Revision:	 00
>>>> Title:		 Normalization Marker for AF PHB Group in DiffServ
>>>> Creation date:	 2013-02-08
>>>> WG ID:		 Individual Submission
>>>> Number of pages: 15
>>>> URL:             http://www.ietf.org/internet-drafts/draft-lai-tsvwg-normalizer-00.txt
>>>> Status:          http://datatracker.ietf.org/doc/draft-lai-tsvwg-normalizer
>>>> Htmlized:        http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-00
>>>> 
>>>> 
>>>> Abstract:
>>>>  This memo describes a Normalization Marker (NM) at DiffServ (DS)
>>>>  nodes to normalize the distribution of DS codepoint (DSCP) markings
>>>>  for an Assured Forwarding (AF) Per-Hop Behavior (PHB) group.  NM is
>>>>  useful for traffic conditioning with Active Queue Management (AQM)
>>>>  when the AF PHB group is deployed for multimedia service classes that
>>>>  carry video packets with advanced codec technologies.  Using NM can
>>>>  offer an incentive that is however missing in today's ecosystem of
>>>>  practical deployment, i.e., when congestion occurs in the AF PHB
>>>>  group, the network should allow a video codec to benefit from its
>>>>  effort of generating finer layers of intra-flow precedence (IFP) with
>>>>  discardable packets in a more balanced distribution.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> The IETF Secretariat
>>>> 
>>> 
>>> -- 
>>> ---
>>> Toerless Eckert, [e-mail]
>>> Cisco NSSTG Systems & Technology Architecture
>>> SDN: Let me play with the network, mommy!
>>> 
>> 
> 
> -- 
> ---
> Toerless Eckert, [e-mail]
> Cisco NSSTG Systems & Technology Architecture
> SDN: Let me play with the network, mommy!
>