Subject: About the importance of packets in a single data stream

From: Michael Welzl <[email-masked]>
Date: Sat, 12 Oct 2013 08:11:59 +0200

Hi,

I'll begin by apologizing for asking what I'm quite sure is a terribly stupid question to many of you.

The question is:

It has long been known that media data can have different levels of importance. Simply put, if packet #1 from a single source contains parts of a video's I-Frame and packet #2 contains only parts of B-Frames, and both end up in the same queue, controlled by an AQM (for instance), it would be better for the video stream if packet #2 would be dropped rather than packet #1.

There is nothing new with this story; it's not hard to find research papers that document various variations of this theme, showing benefits in video quality.

My question is, why is none of this happening?

Is it because DSCP values are typically associated with sources, and hence, marking packet #2 as "less" important would put the source at the risk of having its packets less important than not only its own other packets, but anybody else's?  But there is equipment that does per-connection stuff, and such things could probably better be done near the edges, where the bottleneck typically is... so if that's the whole issue, we could define DSCP values that mean relative importance *within the same five-tuple only*. Surely that has been thought about and probably proposed by folks before, so what happened? Why isn't it done?

Or is it because per-five-tuple-functionality in the network is regarded as being too costly, and not encouraged, and hence not standardized?

I'm just trying to understand the reasons for this particular long-standing difference between research an reality.

Cheers,
Michael

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 12 Oct 2013 08:28:10 +0200 (CEST)

> My question is, why is none of this happening?

My guess is that the rule to always deliver packets within a stream in 
order. If packets within the same stream have different DCSP values, there 
is a risk that they will go into different queues and they might be 
delivered out of order. A lot of applications that do real-time will have 
a PDV buffer, but won't have much of a out-of-order buffer. If a packet 
with sequence number 10 arrives after sequence number 8, packet number 9 
is often assumed to be lost.

AQM is not widely deployed at all on the Internet as it is today, and a 
lot of devices will just have 4 different queues. Also as you say below, 
putting packets into different queues might mean they compete with other 
traffic and you might get packet loss due to that.

It would of course be of interest going forward to look into your 
proposal. AQM/Bufferbloat movement could perhaps benefit from this, but 
the current thinking is to make sure that all streams get equal access to 
the media with minimal influence between them, not that much to decide 
what packets within a stream to select for drop.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Michael Welzl <[email-masked]>
Date: Sat, 12 Oct 2013 10:28:48 +0200

On 12. okt. 2013, at 08:28, Mikael Abrahamsson <[email-masked]> wrote:

> My guess is that the rule to always deliver packets within a stream in order. If packets within the same stream have different DCSP values, there is a risk that they will go into different queues and they might be delivered out of order. A lot of applications that do real-time will have a PDV buffer, but won't have much of a out-of-order buffer. If a packet with sequence number 10 arrives after sequence number 8, packet number 9 is often assumed to be lost.
> 
> AQM is not widely deployed at all on the Internet as it is today, and a lot of devices will just have 4 different queues. Also as you say below, putting packets into different queues might mean they compete with other traffic and you might get packet loss due to that.
> 
> It would of course be of interest going forward to look into your proposal. AQM/Bufferbloat movement could perhaps benefit from this, but the current thinking is to make sure that all streams get equal access to the media with minimal influence between them, not that much to decide what packets within a stream to select for drop.

Thanks, that's about what I guessed... strange, a bit, given that it's not hard to show quite large quality gains if packet priorities within a stream (five-tuple) are honored, and doing per-5-tuple things near the edge doesn't seem all too unusual to me...

So indeed it wasn't a proposal, I was just wondering why it's not done. Maybe not enough interest from the parties involved (because application developers are not usually the same people that build middle-boxes)

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Sat, 12 Oct 2013 10:32:50 +0200

On 12. okt. 2013, at 08:53, Varun Singh <[email-masked]> wrote:

> Hi Michael,
> 
> In my experience, Video telephony applications do not generate any
> b-frames. So #2 packets do not exist. Secondly some generate I-frames
> only when they really have to (scene change or decoding packet chain
> is corrupted) otherwise their GOP is set to infinity.

But packet importance is more than just I- vs. P- vs. B-Frames - there are blocks that depend on each other, and the more data depends on data in a packet, the more important that packet gets.

> For sending I-frames, there are many tricks that a sending endpoint
> can play, it doesn't need to burst the whole frame immediately, it can
> pace out (there are 10s of milliseconds) before the next frames is
> generated. Alternatively, if the frame is too large, they can send
> parts of the I-frame with the subsequent frames, this potentially
> delays rendering. I don't know if any of these have been standardized.

Probably no need to standardize this?

> If a part of a frame is lost, the receiver can send a NACK or packet
> loss indication Or reference picture selection.
> 
> Another way is that the sending point uses unequal level of protection
> (ULP) ie., not all packets or frames are FEC'ed.
> Lastly it can vary the packet size, ie., it may do this by varying the
> size of slices (combinations of macro blocks).
> 
> Applicability of ARQ typically depends on observed end-to-end delay
> and observed losses. The endpoint won't send a nack or a
> retransmission if there are too many losses or if it thinks it won't
> reach in time for decoding.

Yes - the choices are really:
1. add FEC for the more important packets
2. do ARQ when applicable for the more important packets
3. somehow tell the network about the more important packets  (but you can't, normally)

and there are trade-offs between these choices. I just wonder if we need 3. as a part of the API to transport?

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Sat, 12 Oct 2013 11:43:12 +0200

On 12. okt. 2013, at 10:49, Varun Singh <[email-masked]> wrote:

> Hi Michael,
> 
> On Sat, Oct 12, 2013 at 11:32 AM, Michael Welzl <[email-masked]> wrote:
>> 
> At the moment, some systems use unequal level of protection (UEP) to protect
> the packets they think are more important, I suppose what you are proposing is
> to add a kill bit in the packets that are less important.

Exactly...

> I think there is a tradeoff, redundancy causes overhead (which the
> endpoint should
> control) and adding priorities pushes the responsibility to the
> middlebox and in both
> the mechanisms, the sender should probably adapt its rate based on
> input from the receiver.

Exactly

> Depends where this is done, at the RTP level or elsewhere. If at the RTP level
> there probably needs to be some guidance on how the bits are fed to the decoding
> pipeline from the RTP layer.

> when you say transport, you mean DSCP codepoint to indicate to the
> middleboxes along the path or
> an API from the codec to the transport (RTP/UDP) at the sending endpoint?

I was really only thinking aloud - but what I was thinking about was indeed a DSCP codepoint that is set because the codec has told the transport about it, in the API, defined by RMCAT.

Cheers,
Michael

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 12 Oct 2013 14:00:05 -0700

[BA] A few points: 

a. No B-frames in interactive uses, as others  have said. 
b. With SVC, you can apply FEC or RTX only to the base layer.   So if there is loss in the base, you can recover.  Loss in enhancement layers may be "lived with" by dropping down to base frame rate/resolution/quality.  So not essential to apply FEC, RTX (or QoS) to enhancement layers, especially since if there is high loss in enhancement layers a logical response is to stop sending them (duh).

---

From: Michael Welzl <[email-masked]>
Date: Sun, 13 Oct 2013 10:01:33 +0200

> b. With SVC, you can apply FEC or RTX only to the base layer.   So if there is loss in the base, you can recover.  Loss in enhancement layers may be "lived with" by dropping down to base frame rate…

I see. Well, should we perhaps really suggest a "lower-priority-than-other-packets-in-the-same-5-tuple" DSCP then?

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Sun, 13 Oct 2013 18:28:34 +0200

IP? with a clear "per-5-tuple-only" rule?

Sent from my iPhone

On 13. okt. 2013, at 17:29, Kevin Gross <[email-masked]> wrote:

> There have been mechanisms proposed or implemented to some extent in Ethernet, ATM and IP for indicating drop precedence (as opposed to class). These mechanisms are designed to solve exactly this problem. I'm not sure why this capability has, by and large, not been widely deployed. I think, for one, we network propeller-heads tend to overestimate the importance of QoS or at least the ability of application designers and IT personnel to get their heads around it well enough to be able to configure it so that it actually improves things.
> 
> Kevin Gross
> +1-303-447-0517
> Media Network Consultant
> AVA Networks - www.AVAnw.com
> 
> 
> On Sun, Oct 13, 2013 at 2:01 AM, Michael Welzl <[email-masked]> wrote:
>

---

From: Steven Blake <[email-masked]>
Date: Mon, 14 Oct 2013 20:58:25 -0400

On Sat, 2013-10-12 at 08:11 +0200, Michael Welzl wrote:

> It has long been known that media data can have different levels of
> importance. Simply put, if packet #1 from a single source contains
> parts of a video's I-Frame and packet #2 contains only parts of
> B-Frames, and both end up in the same queue, controlled by an AQM (for
> instance), it would be better for the video stream if packet #2 would
> be dropped rather than packet #1.
> 
> There is nothing new with this story; it's not hard to find research
> papers that document various variations of this theme, showing
> benefits in video quality.
> 
> Is it because DSCP values are typically associated with sources, and
> hence, marking packet #2 as "less" important would put the source at
> the risk of having its packets less important than not only its own
> other packets, but anybody else's?  But there is equipment that does
> per-connection stuff, and such things could probably better be done
> near the edges, where the bottleneck typically is... so if that's the
> whole issue, we could define DSCP values that mean relative importance
> *within the same five-tuple only*. Surely that has been thought about
> and probably proposed by folks before, so what happened? Why isn't it
> done?
> 
> Or is it because per-five-tuple-functionality in the network is
> regarded as being too costly, and not encouraged, and hence not
> standardized?
> 
> I'm just trying to understand the reasons for this particular
> long-standing difference between research an reality.

The Assured Forwarding (AF) PHB group (RFC2597) was defined precisely to
enable this drop-precedence-without-reordering-packets-within-a-flow
behavior.  In Diffserv jargon (RFC3260), an instance of an AF behavior
aggregate (BA), e.g., AF11/AF12/AF13, would be an ordered aggregate
(OA).  Packets in a flow DSCP-encoded with either AF11/AF12/AF13 (for
example) are guaranteed to be transmitted in the order received, but
will have different drop precedences (AF11 highest; AF13 lowest).  This
is usually achieved by serving all packets on a port with the AF1* DSCP
via the same FIFO queue.

Regards,

// Steve

---

From: Michael Welzl <[email-masked]>
Date: Tue, 15 Oct 2013 10:14:45 +0200

> is usually achieved by serving all packets on a port with the AF1* DSCP

No, this is not what I mean. From RFC2597:

In a DS node, the level of forwarding assurance of an IP packet thus
depends on (1) how much forwarding resources has been allocated to
the AF class that the packet belongs to, (2) what is the current load
of the AF class, and, in case of congestion within the class, (3)
what is the drop precedence of the packet.

So while AF PHB groups are indeed meant to address such per-flow drop precedence, we still have a per-aggregate function, meaning that it's risky business for an application to decide that some of its packets have a higher drop precedence (it might put the application at a disadvantage in comparison with other *users*).

If you just look at page 4 of http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-02 (Flow A vs. Flow B) you'll see an example that explains exactly the problem I'm talking about. Indeed I think that this draft suggests a nice solution, but as long as an application doesn't know that the mechanism in this draft is in place everywhere, the incentive for an application to assign a higher drop precedence to some packets still isn't there.

For how I think this could be solved, see my previous email to Toerless.

Cheers,
Michael

---

From: Michael Welzl <[email-masked]>
Date: Wed, 16 Oct 2013 09:36:06 +0200

[I'm adding tsv-area: I noticed it was dropped from some part of this thread, but I think unintentionally? BTW I hope tsv-area is appropriate, and not tsvwg? I started off to rmcat and tsv-area because I had a general DiffServ'ish question, yet related to rmcat, and so I thought this would fit.]

Hi,

Imagine that you write an application and based on the intra-flow priorities of your packets you decide that this would be your profile:
(copy+paste from the draft)

***
      Flow B

         40% or 2Mbps in AF41

         40% or 2Mbps in AF42

         20% or 1Mbps in AF43
***

...and the normalizer is not present in the network, and you get "normal" DiffServ behavior (because we're using the standard AF codepoints). Now, if someone else uses:

***
      Flow A

         80% or 4Mbps in AF41

         20% or 1Mbps in AF42

          0% or 0Mbps in AF43
***

...then this someone (flow A) would be better off in the presence of congestion, as described in the draft. This means that you'll never decide for a profile as in Flow B in your application because you could hurt yourself, you might be treated worse than some other users.

This is what the normalizer fixes, but as long as you don't know it's there, going for a profile as in Flow B is still risky business.

"You" in my story here is the application programmer, and it really has to be the application programmer doing this - the priorities would be derived from knowledge about the codec, FEC usage etc. What the application programmer needs is a signal that is definitely going to be ignored unless it hits a normalizing ingress device.

Cheers,
Michael

On 16. okt. 2013, at 05:31, Kevin Gross wrote:

> As I read it, the proposal in the draft is to have network equipment tweak DSCP values at ingress points so that drop precedence proportions are normalized in some way. This does not require that all senders produce normalized streams. The only thing that needs to be accepted is common normalization profiles for all the ingress points in the network. Under the proposal, useful drop precedence behavior becomes a network configuration issue, not a standards compliance issue.
> 
> Kevin Gross
> +1-303-447-0517
> Media Network Consultant
> On Tue, Oct 15, 2013 at 8:13 PM, Toerless Eckert <[email-masked]> wrote:
> Partially true IMHO.
> 
> Yes, if we could have all flows agree to have a marking let's say 20% high,
> 60% normal and 20% low prio bits (long term average), then we would not
> need normalization. If there is any chance to establish such a standard, that
> would be gret.
> 
> It just doesn't change the problem of DSCP. It would change the PHB though
> by making it much more strict. Which makes it more questionable whether it
> would be accepted.
> 
> 
> Cheers
>     Toerless
> 
> 
> On Tue, Oct 15, 2013 at 07:34:18PM -0600, Kevin Gross wrote:
> > If we create a situation where all flows are "normalized" (i.e. a certain
> > percentage of their packets are marked with higher drop precedence) by the
> > network then we shouldn't have to deal with things on a per-flow basis. If
> > we're not dealing with things on a per-flow basis, we can use the existing
> > AF codepoints. Dropping according to drop precedence markings on a class
> > basis should be statistically fair to all flows so long as all flows have
> > been normalized.
> >
> > Kevin Gross
> > +1-303-447-0517
> > Media Network Consultant
> > AVA Networks - www.AVAnw.com <http://www.avanw.com/>
> >
> >
> > On Tue, Oct 15, 2013 at 6:23 PM, Toerless Eckert <[email-masked]> wrote:
> >
> > > The method described in the draft is applicable to whatever marking one
> > > wants
> > > to use. I wish DSCP was the solution because as you said it would avoid
> > > the need
> > > for figuring out how to carry a new marking (like RTP header extensions).
> > >
> > > But: There are no existing DSCP with the PHB of "intra-flow-priority" with
> > > a
> > > guarantee that flows with different distributions of those priorities
> > > would see
> > > the same percentage of drops under queue congestion.
> > >
> > > If we wanted to go the DSCP route, we would need at least 3 new DSCP to
> > > indicate
> > > high,normal,low intra-flow priority (and just for intelligent dropping, 3
> > > actually
> > > might be good enough). But 3 new DSCP is an act of god in the IETF.
> > >
> > > Then those three new DSCP would not only have to indicate intra-flow
> > > priority but
> > > also the overall class PHB that the traffic should have even without
> > > priority
> > > indications. Aka: lets say low loss, low latency, appropriate for RMcat.
> > > So when the next class of traffic with different intra-flow priorities
> > > comes
> > > along, we'd have to redo the whole DSCP exercise again. And again.
> > >
> > > And then the DSCP still get reset along the path, and apps still have
> > > problems
> > > setting DSCP across various OSs.
> > >
> > > Cheers
> > >     Toerless
> > >
> > > On Tue, Oct 15, 2013 at 04:45:11PM -0600, Kevin Gross wrote:
> > > > Maybe I skimmed it too quickly but my understanding is that the proposal
> > > is
> > > > to remark DSCP values at the ingress point of the network and possibly at
> > > > other key boundaries too. Such DSCP remapping is already common practice
> > > in
> > > > enterprise networks.
> > > >
> > > > The twist here is that the remapper will do the remapping dynamically
> > > based
> > > > on the proportion of AFn1, AFn2 and AFn3 packets received from a sender.
> > > A
> > > > greedy sender that it producing only AF41 markings will get some of those
> > > > randomly remarked as AF42 and AF43.
> > > >
> > > > The proposal uses existing DSCP values and it doesn't look like signaling
> > > > is necessary nor is it necessary for the application to know that this is
> > > > happening.
> > > >
> > > > Kevin Gross
> > > > +1-303-447-0517
> > > > Media Network Consultant
> > > > AVA Networks - www.AVAnw.com <http://www.avanw.com/>
> > > >
> > > >
> > > > On Tue, Oct 15, 2013 at 2:43 PM, Michael Welzl <[email-masked]>
> > > wrote:
> > > >
> > > > > Hmm. Whether the balance is right or not might depend on how the
> > > signaling
> > > > > is done. Anyway, unless I misunderstood something, the way the
> > > normalizer
> > > > > now stands it won't really make a change: it gives an incentive to
> > > > > applications to mark some packets with higher drop precedence, yet
> > > requires
> > > > > applications to know that the normalizer is in place or else the
> > > service
> > > > > would be different.
> > > > >
> > > > > Maybe different DSCP values would be needed - but then this can't be
> > > used
> > > > > in combination with "regular" DiffServ usage. It really depends on the
> > > > > signaling - ideas are now being tossed around by Colin and Toerless,
> > > who
> > > > > clearly both know more about what the right signaling could be than me.
> > > > >
> > > > > Cheers,
> > > > > Michael
> > > > >
> > > > >
> > > > > On 15. okt. 2013, at 19:04, Kevin Gross <[email-masked]> wrote:
> > > > >
> > > > > I think you're stretching here. I don't think the balance is right. The
> > > > > proposed information is difficult to retrieve and of little use to
> > > much of
> > > > > the network. Even if standardized, it is unlikely to be successful.
> > > > >
> > > > > The ideas in the normalizer draft don't seem to have so many issues
> > > and I
> > > > > think it answers your original question and sets out to achieve what
> > > you're
> > > > > looking for.
> > > > >
> > > > > Kevin Gross
> > > > > +1-303-447-0517
> > > > > Media Network Consultant
> > > > > AVA Networks - www.AVAnw.com <http://www.avanw.com/>
> > > > >
> > > > >
> > > > > On Tue, Oct 15, 2013 at 1:59 AM, Michael Welzl <[email-masked]>
> > > wrote:
> > > > >
> > > > >> Hi,
> > > > >>
> > > > >> I'll dissect your second and third sentences and tell you what I think
> > > > >> about each part  :-)   below:
> > > > >>
> > > > >>
> > > > >> On 14. okt. 2013, at 23:35, Kevin Gross wrote:
> > > > >>
> > > > >> > No, not per 5 tuple (per flow). I don't think that is something we
> > > > >> should ask of the network.
> > > > >>
> > > > >> I agree that asking this of the network may seem like encouraging
> > > > >> per-flow functionality; in particular, if we'd put this into IP, that
> > > would
> > > > >> be ugly. However, it's just a matter of fact that there are devices
> > > that do
> > > > >> identify flows, and then, why not give such devices some guidance?  I
> > > like
> > > > >> Toerless' suggestion of making this an RTP header extension field: if
> > > a
> > > > >> device is identifying flows, we can expect such a device to identify
> > > such a
> > > > >> field too. Plus, if we think of end systems playing an intermediate
> > > system
> > > > >> role in RTP (mixers, ..), these devices might also benefit from that
> > > sort
> > > > >> of information.
> > > > >>
> > > > >>
> > > > >> > It doesn't sit well with the end-to-end principle
> > > > >>
> > > > >> I disagree, this is an all-too-common misunderstanding of the
> > > end-to-end
> > > > >> principle: it only says that whatever can be done in the application
> > > should
> > > > >> be left up to the application, but it doesn't say that you mustn't
> > > identify
> > > > >> application streams inside the network or "keep the network simple and
> > > > >> stupid". If you do "keep the network stupid", you're definitely in
> > > line
> > > > >> with the e2e argument, but the argument isn't as strict as that (a
> > > typical
> > > > >> example is routing, which can well become as complex as you wish,
> > > without
> > > > >> harming the end-to-end principle). Now here we're discussing a
> > > function
> > > > >> where the application really can't help you: when congestion happens
> > > inside
> > > > >> the network and a packet must be dropped there, the best the
> > > application
> > > > >> can do is tell you which packet to drop.
> > > > >>
> > > > >>
> > > > >> > and it won't scale.
> > > > >>
> > > > >> I agree. But it doesn't have to, just because we introduce the signal
> > > we
> > > > >> don't harm scalability - devices at the edges of the network could
> > > deal
> > > > >> with it, all other devices could ignore it.
> > > > >>
> > > > >> Cheers,
> > > > >> Michael
> > > > >>
> > > > >>
> > > > >
> > > > >
> > >
> > > --
> > > ---
> > > Toerless Eckert, [email-masked]
> > > Cisco NSSTG Systems & Technology Architecture
> > > SDN: Let me play with the network, mommy!
> > >
> > >
> 
> --
> ---
> Toerless Eckert, [email-masked]
> Cisco NSSTG Systems & Technology Architecture
> SDN: Let me play with the network, mommy!
> 
>

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Wed, 16 Oct 2013 10:21:42 +0200

Hi Michael,

On 16.10.2013 09:36, Michael Welzl wrote:
> [I'm adding tsv-area: I noticed it was dropped from some part of this
> thread, but I think unintentionally? BTW I hope tsv-area is appropriate,
> and not tsvwg? I started off to rmcat and tsv-area because I had a
> general DiffServ'ish question, yet related to rmcat, and so I thought
> this would fit.]

Yes, I'm following this on TSVAREA since I'm not subscribed on rmcat yet.

> ...then this someone (flow A) would be better off in the presence of
> congestion, as described in the draft. This means that you'll never
> decide for a profile as in Flow B in your application because you could
> hurt yourself, you might be treated worse than some other users.
> 
> This is what the normalizer fixes, but as long as you don't know it's
> there, going for a profile as in Flow B is still risky business.
> 
> "You" in my story here is the application programmer, and it really has
> to be the application programmer doing this - the priorities would be
> derived from knowledge about the codec, FEC usage etc. What the
> application programmer needs is a signal that is definitely going to be
> ignored unless it hits a normalizing ingress device.

Just some few observations from my point of view:
- DiffServ doesn't distinguish between individual flows within
  a behavior aggregate - it was intentionally designed that way.
  Per micro-flow unfairness within the same class is not prevented
  by DiffServ - conceptionally you should only use the first-hop router
  for this kind of traffic conditioning measures. However, this doesn't
  help to prevent other aggregation effects inside a DiffServ domain
  (cf. Per-Hop Behavior vs. Per Domain Behavior).

- Following the end-to-end argument, it doesn't make sense to build
  somewhat complex mechanisms into the network, which may even depend
  on the particular application (like WebRTC etc.) - so building a
  "normalizer" (w/o having fully understood the concept) into the
  network doesn't seem to be the right approach in the long run.

- Therefore, I agree very much with your last statement: it's only
  the application that has the knowledge and context to set any
  kind of forwarding priority (or drop precendence) for individual
  packets correctly.
  Especially, the logic to react on dropped packets should reflect
  the marking and corresponding dropping behavior.

Regards,
 Roland

---

From: Michael Welzl <[email-masked]>
Date: Wed, 16 Oct 2013 10:49:02 +0200

> Yes, I'm following this on TSVAREA since I'm not subscribed on rmcat yet.

... and dropping tsv-area was a mistake, as your message shows  :(   'cause we've been around this block I think...

>  (cf. Per-Hop Behavior vs. Per Domain Behavior).

Sure-

>  network doesn't seem to be the right approach in the long run.

I disagree with what you say about e2e, see:
http://www.ietf.org/mail-archive/web/rmcat/current/msg00519.html
but anyway that's a separate debate, as the normalizer draft works on aggregates and is really compliant with DiffServ as far as I can tell.
That's the draft we're debating here:
http://tools.ietf.org/html/draft-lai-tsvwg-normalizer-02

>  the marking and corresponding dropping behavior.

Yeah, the issue we're debating is that an application won't have an incentive to go for the profile of Flow B (page 4 of the draft) unless it knows that the normalizer is there, because otherwise it could get treated in the normal DiffServ way and that would make it worse off than Flow A (page 4 of the draft). Thus you need a way for the application to signal intra-flow packet priorities to an edge without "standard DiffServ" operating on that signal. The signal must be ignored unless the normalizer is there.

I hope that helped to clarify the discussion a bit...

Cheers,
Michael

---

From: Roland Bless <[email-masked]>
Date: Wed, 16 Oct 2013 21:43:16 +0200

Hi Michael and all,

Am 16.10.2013 10:49, schrieb Michael Welzl:
> but anyway that's a separate debate, as the normalizer draft works on
> aggregates and is really compliant with DiffServ as far as I can tell.

Thanks for the pointer, I quickly read over it.
My understanding is: if we have an example flow
of AF41:AF42:AF43 80:20:0 the normalizer would
reassign those packets to 40:20:20 (or whatever
the configured proportion is). Is this perception
correct?

Regarding the e2e argument:
- you said "it only says that whatever can be done in the application
  should be left up to the application" - I don't think this catches
  the gist of it: "The function in question can completely and
  correctly be implemented only with the knowledge and help of the
  application standing at the end points of the communication system.
  Therefore, providing that questioned function as a feature of the
  communication system itself is not possible". => especially,
  application knowledge is often required when reacting on failures,
  i.e., the right decision cannot be made when implemented within the
  network. Thus, dropping packets according to the markings set by
  the application is fully in accordance with the e2e argument, whereas
  building marking mechanisms into the network that require application
  knowledge is usually not in accordance with it.

- if I understood the normalizer proposal in draft-lai-tsvwg-normalizer-02
  correctly, it is not in line with the e2e argument since it reassigns
  drop precedences without application knowledge. Thus, it may make
  the wrong decisions about the importance of packets, not knowing how
  apps react to loss.

> Yeah, the issue we're debating is that an application won't have an
> incentive to go for the profile of Flow B (page 4 of the draft) unless
> it knows that the normalizer is there, because otherwise it could get
> treated in the normal DiffServ way and that would make it worse off than
> Flow A (page 4 of the draft). Thus you need a way for the application to
> signal intra-flow packet priorities to an edge without "standard
> DiffServ" operating on that signal. The signal must be ignored unless
> the normalizer is there.
> 

Thanks, I think I understand the rationale now. However, I see several
potential problems with this approach and have some thoughts to share
as well:
0) I think an application with a 40:20:20 assignment has no real problem
   if it experiences loss in PHBs AFx2, AFx3 since it was designed that
   way. Whether it's "unfair" w.r.t. to other streams doesn't really
   matter. Remember that QoS support is usually managed unfairness
   anyway. Fairness within AF usually matters for the "yellow" packets,
   e.g., AFx2. This excess bandwidth should be fairly shared among all
   streams in this AF class if possible.

1) reassignment of drop precedences w/o application knowledge

2) how can one find the right default proportions suitable for different
   streams or applications?

3) Is this AF PHB class restricted to forward this special kind of
   encoded video streams? If so, we already have the problem of
   knowing that this is actually the case in the particular DS
   domain/region...

4) Normalizing other (non video) streams within the same AF class may
   cause adverse effects to the application behavior.

5) Aggregation effects within a domain in interior nodes may cause
   a different proportion than what the normalizer is configured for.
   Thus the normalizer may not cause the desired effects for a whole
   domain.

6) The AF PHB group per se is difficult to handle, since drop
   precedences may be even inconsistenly configured within a DS domain
   or DS region (see RFC 2597, sec. 4 at the end: "Inconsistent discard
   behaviors lead to inconsistent end-to-end service semantics and
   limit the range  of possible uses of the AF PHB in a multi-vendor
   environment.").
   Furthermore, packets of lowest drop precedence may suffer from
   packets with higher drop precedences waiting before them in the
   queue.

7) For an AF class you basically need a sort of admission control for
   the assured (let's say "green") AFx1 packets to guarantee the low
   loss probability. Every usage of excess bandwidth is purely optional
   for which the application must be prepared.

Regards,
 Roland