[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
> AVA Networks - www.AVAnw.com
>
>
> On Tue, Oct 15, 2013 at 8:13 PM, Toerless Eckert <[email protected]> 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 protected]> 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 protected]>
> > > 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 protected]> 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 protected]>
> > > 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 protected]
> > > Cisco NSSTG Systems & Technology Architecture
> > > SDN: Let me play with the network, mommy!
> > >
> > >
>
> --
> ---
> Toerless Eckert, [email protected]
> Cisco NSSTG Systems & Technology Architecture
> SDN: Let me play with the network, mommy!
>
>
