Re: [conex] New concepts text in draft-ietf-conex-concepts-uses

[Bob Briscoe <[e-mail]>]

Mikael,

At 14:32 21/07/2011, John Leslie wrote:
>Mikael Abrahamsson <[e-mail]> wrote:
> > On Tue, 19 Jul 2011, John Leslie wrote:
> >
> >> But if an ingress policer is close enough to the source it needn't be
> >> flow-aware -- the user is in the best position to balance demands of
> >> different flows, and the policer merely needs to enforce an overall
> >> limit.
> >
> > I don't see the need for anything more than we have today then? What would
> > a conex enabled policer give if it's one policer per access port anyway?
>
>    It would likely drop packets which exceed the Congestion-Expected
>allowance. (This is by no means the only possibility, but it seems the
>most likely.)
>
> > And how would it work when it's connected to an ISP<->ISP peering port?
>
>    It would likely drop packets which exceed the Congestion-Expected
>allowance. (Here other options seem less unlikely...)
>
> >> If, OTOH, various users are aggregated before the ingress policer,
> >> the ingress policer is in a very poor position to sort them out --
> >> especially with forging of source addresses being so easy. I think we're
> >> wasting our time to try.
> >
> > I always thought the policer acted on aggregation ports, ie for several
> > users.
>
>    That is an implementation choice. There are setups where you can be
>quite confident which customer sent you the packet without depending on
>source address. And there are situations in which trusting the source
>address is reasonable. But IMHO, trying to distinguish flows would be
>a poor practice. YMMV, of course...

The idea is for ConEx info to be used to 'sanction' the immediately 
connected entity, not the entities the other side of it. Then the 
immediately connected entity can sanction its immediately connected 
entities if it so wishes.

If you do something else, it's up to you, but you're relying on 
network layer source addresses, and wasting a system (ConEx) that was 
deliberately arranged not to have to.

However, the deployment story for ConEx is a single network first, 
where this issue doesn't arise. It's only worth using ConEx in 
multiple networks once you have ECN as well (as you yourself have 
also pointed out).


> >>> Show congestion to everybody, the user and ISP alike.
> >>
> >> Do you mean something beyond simply having in the IP packet in a
> >> well-known place? If so, what?
> >
> > I'm talking the congestion signals (re-ECN etc) that seems to be the
> > centarl goal of ConEx.
>
>    They, by definition, will be in a well-known place in the packet.
>
> >>> I would like to see it also differentiate between self-congestion
> >>> (access link) and shared-link congestion (everything else than the
> >>> access link), but I have no idea how to do this.
> >>
> >> Neither do I... nor do I see any benefit. At any point, it's trivial
> >> to distinguish upstream from downstream.
> >
> > There is tremendous benefit from differentiating "my access link is
> > congesting because *I* am using it" to "my ISP doesn't have enough
> > capacity so because of *others* I can't use my full access speed", for
> > the user point of view.
>
>    I can't think of a way to do that without cooperation by your ISP.
>However, the likes of DSLreports ought to be able to estimate congestion
>within your ISP...

In the downstream, DSL is arranged so that the per-CVLAN queue in the 
BRAS models that customer's DSL line and drops packets as if it had a 
capacity equal to the line. Then separately there is the scheduling 
to share the backhaul network (the link between the BRAS and the 
DSLAM), which is typically a WRR scheduler also in the BRAS.

In a single network scenario, we can assume there is little loss 
upstream of the BRAS if the traffic is coming from a data centre over 
a core network. Therefore, for each customer, subtracting loss in the 
WRR queue at the BRAS from their ConEx markings will give the loss in 
the (modelled) access line.

If you also had ECN in the upstream access you can do similar tricks 
in the upstream direction. But even without ECN, at least doing it in 
the downstream is one better than anything else that can't do it at all.

However, I also wanted to interject here for a more basic 
explanation. Congestion is a property of a link or path that is the 
same for everyone using it. Whereas congestion-volume is a property 
of each user's traffic, measured by counting ConEx markings on only 
the packets of that user.

ConEx isn't merely trying to find how congested a link is. We can 
already do that. ConEx is trying to attribute which traffic 
contributed how much to the congestion. If Alice sends all her volume 
when the link is congested while Bob sends the same volume when it 
isn't, the DSL reports could be the same, but the congestion-volumes 
will be very different.



> >> Oh, but we do. Any congestion on the return-path from receiver to
> >> sender is Somebody-Else's-Problem.
> >
> > I don't agree at all. If someone is dropping the traffic I'm about to
> > receive, I want to know about it.
>
>    I think we have a failure-t'communicate here. Any transport receiver
>has to signal back to the sender, which may follow a congested path as
>well. How this is done is not a problem for ConEx to solve.

I agre it's not our direct problem. But in the design of the accurate 
transport feedback <draft-kuehlewind-conex-accurate-ecn> we have 
ensured that the feedback info is robust to ack losses. But that's 
probably just confusing your point, which is in general true.


> >>> Should we give guidance to how the IP stack should expose this
> >>> information to the user?
> >>
> >> I don't understand the question.
> >
> > I want to empower the user with knowledge about congestion. I thought
> > this was a central goal of ConEx, to *expose* congestion.

Quoting conex-concepts-uses:
"2.2.  Non-Goals of ConEx and Common Misconceptions

    Congestion exposure is about the transport sender exposing congestion
    to the network, not the other way round.  That would not make sense
    given by design the transport endpoints already handle congestion in the
    TCP/IP protocol suite.
"

Nonetheless, by exposing congestion to the operator, it makes the 
operator able to do something about the user's congestion, which 
motivates {apps|transport protocols|the user} to do something with 
their pre-existing knowledge of congestion.


>    ... to the network layer: the application layer is awfully far removed
>from that...
>
><snip>
> >
> >> Do you have suggestions on what would help?
> >
> > So, for core links, my suggestion is to use WRED and drop/set ECN at a
> > certain queue depth, for instance 20-30 ms queue depth.

Yup, altho just RED would be enough - maybe you mean that.

>For access links,
> > I'd like to see "fair queuing" (RFC970) enabled on a lot more ADSL/cable
> > modems/Wifi routers, and also in hosts.

FQ crudely carves up each customer's usage into equal bit-rates. 
That's better than nothing, but it's very over-constraining. Quoting 
again from new text in concepts-uses:

"   Since then capacity has been shared by a mix of traffic management
    approaches, partly network-based (weighted round-robin scheduling,
    weighted fair queuing, etc) and partly host-based (TCP).  However, in
    recent years, network operators became concerned that a relatively
    small number of end-machines were consuming a disproportionately high
    share of network resources.  This is actually because both TCP and
    all the traditional network-based approaches only share out a
    bottleneck at each instant.  They fail to take account of how much of
    the time a consumer is keeping the link busy, which is the main
    factor that determines everyone else's bit-rate.
"


> >
> > RFC1254 also lists different ways of handling this. Generally, I'd say not
> > much of this is actually in use on the Internet today, 25+ years later :P
> > I run fair-queue on my access link at home, it works great.

Have you tried running uTP and Web at the same time through your FQ? 
FQ forces them to have equal bit-rate, even tho uTP is trying to 
allow the Web flows to temporarily take more of the capacity.

Also if you put multiple variable bit-rate videos through FQ, it 
forces them all to get constant bit-rate service. Through a given 
backhaul link, relative to CBR, a good VBR codec can get more than 
twice as many videos through. If you turn on FQ, it removes the 
ability to multiplex all the peaks and troughs, and you can only get 
half the videos through, as if they were CBR again. See "Equitable 
quality video streaming over DSL," via 
<http://bobbriscoe.net/projects/refb/index.html#Weighted_andor_Proportionally_Fair>



>    These seem reasonable, but not for ConEx to say...
>
> >> Ah, yes. Buffer tuning is fairly well understood by ISPs, but the
> >> distribution-of-information channels don't work well. :^( If you
> >> think ConEx could help, please say how!
> >
> > Er, considering basically NONE of the typical CPEs in use today does
> > anything other than FIFO with a lot of buffers, I'd say if the ISP
> > understands bufferbloat, they haven't communicated this to the purchasing
> > department who controls CPE purchases, because if they did, the typical
> > ADSL router would do better things than FIFO for upstream buffer
> > management.

Not so. Many home gateways have fairly complex queuing arrangments in 
the upstream with what is essentially simple DPI to classify flows 
into the different queues. Admittedly, many also have rubbish 
implementations and bugs, but we tested many of them and there are a 
few good ones. I'm not saying DPI is a good way to go. I'm just 
saying what's out there.


>    As I said, distribution-of-information channels don't work well. :^(
>
> > So I would like to have ConEx describe how buffering should be implemented
> > in all devices who might experience congestion on the outgoing interface
> > (hosts and routers, most likely different advice, ConEx perhaps should
> > define different classes of devices that should do different things), this
> > should be very good guidance going forward.
>
>    Hmm... I don't see where that fits in our current documents. Perhaps
>you'd like to try writing an Internet Draft?

Altho this isn't the bailiwick of ConEx, this is the goal of a 
different draft that a bunch of us have promised to write, but just 
not got round to it (yet). It's under the ICCRG (IRTF). However, it 
looks like you & I have some disagreements to discuss before we would 
be able to write anything approaching consensus.


Bob


>--
>John Leslie <[e-mail]>
>_______________________________________________
>conex mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/conex

________________________________________________________________
Bob Briscoe,                                BT Innovate & Design