Subject: [p2pi] DSCP or not

From: Toerless Eckert <[email-masked]>
Date: Thu, 31 Jul 2008 07:37:42 -0700

Seems to me as if the best long term solution would be to utilize a scavenger
DSCP class in the network.  For such a class i think the existing
flow control mechanisms as eg: in TCP may not be suited best to exhaust
the available bandwidth - as it likely fluctuates more frequently and
short term than in best effort. SSo some form of agressive transmission with
effecient retransmission (and maybe FEC) is probably best when using
such a scavenger clas.

Practically speaking, it will be a long time for most core networks
to support such a clss, specifically because of the limited number of
exp bits in MPLS, inertia, technical problems, and so on. So now
we need the algorithm to handle scavenger traffic in the best effort class,
that very carefully tries not to cause any congestion and in face of
congestion throttles itself back to zero or close to it.

If we could bring together those two algorithms together, and the
algorithm for a connection would be selected based on whether or not the ntework
resets the scavenger DSCP class to best effort (because there is no scavenger class
configured) ... then i think this would be a good short and long term solution.

Cheers
    Toerless
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 31 Jul 2008 11:48:05 -0400

I don't think we need to wait until a DiffServ/scavenger service is  
supported across the backbone. Most of the problems are in the access  
networks (both within a residence and in the first mile), where  
deploying DiffServ seems much more realistic. The backbone network  
should presumably leave the DSCP alone in transit, but even that isn't  
all that important, since the important link limit in both cable and  
DSL is the uplink. I don't know if and how DOCSIS can manage  
transmission slots on the uplink based on DiffServ, however.

Henning

---

From: John Leslie <[email-masked]>
Date: Thu, 31 Jul 2008 11:50:16 -0400

Toerless Eckert <[email-masked]> wrote:
> 
> Seems to me as if the best long term solution would be to utilize a
> scavenger DSCP class in the network.

   Possibly, but this is "long-term" and requires wide enough deployment
of the "scavenger DSCP class"...

> For such a class i think the existing flow control mechanisms as eg:
> in TCP may not be suited best to exhaust the available bandwidth -
> as it likely fluctuates more frequently and short term than in best
> effort.

   Hard to say -- it depends so much upon buffer sizes and RTT: but
certainly for small enough buffer sizes and large enough RTT this would
be a problem.

> So some form of agressive transmission with effecient retransmission
> (and maybe FEC) is probably best when using such a scavenger class.

   That doesn't necessarily follow...

   We do want to keep the bottleneck buffer full enough; but we'd much
prefer to never fill it so much as to drop our packet(s).

> to support such a class, specifically because of the limited number
> of exp bits in MPLS, inertia, technical problems, and so on.

   I'd list "inertia" first (and I'm not sure the others even apply).

> So now we need the algorithm to handle scavenger traffic in the best
> effort class, that very carefully tries not to cause any congestion
> and in face of congestion throttles itself back to zero or close to it.

   This does look like our best bet short-term.

> algorithm for a connection would be selected based on whether or not
> the network resets the scavenger DSCP class to best effort (because
> there is no scavenger class configured) ... then i think this would
> be a good short and long term solution.

   I would prefer not to concern ourselves with guessing what the future
may bring in "network" support of DSCP. It's really unlikely that we'll
see "enough" DSCP support within five years.

   Instead, I look at the actual situation driving this work, and I see
a great likelihood of the bottleneck being the uplink from a customer
site. To me, this almost shouts, "backpressure solution needed."

   If the customer's ISP runs an ALTO server, that server _should_ be
in a "good enough" position to signal the backpressure. It does tend
to change the way we look at developing an ALTO protocol, but IMHO
the payoff could be significant...

--
John Leslie <[email-masked]>
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: Lars Eggert <[email-masked]>
Date: Thu, 31 Jul 2008 18:02:30 +0100

> DSCP class in the network.

RFC3662 was published five years ago. Even assuming slow adoption, we  
should have heard from some operators that use it by now. I'm not  
aware of any deployment.

I agree that universal deployment of DiffServ scavenger service would  
be the better solution, but it looks unlikely it will happen. A  
transport-level solution that approximates what the DiffServ solution  
would give us, but with a different (better?) incentive angle, seems  
attractive.

Lars

---

From: David R Oran <[email-masked]>
Date: Thu, 31 Jul 2008 13:05:38 -0400

On Jul 31, 2008, at 11:48 AM, Henning Schulzrinne wrote:

> supported across the backbone. Most of the problems are in the  
> access networks (both within a residence and in the first mile),  
> where deploying DiffServ seems much more realistic. The backbone  
> network should presumably leave the DSCP alone in transit, but even  
> that isn't all that important, since the important link limit in  
> both cable and DSL is the uplink. I don't know if and how DOCSIS can  
> manage transmission slots on the uplink based on DiffServ, however.
>
Yes.

>> scavenger

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Thu, 31 Jul 2008 19:52:41 +0200

> Seems to me as if the best long term solution would be to 
> utilize a scavenger DSCP class in the network.  

make sense. the real question is the how long would it take for an
RFC3662-like DSCP to be deployed and this depends on which extend. on
the other hand, now that need has been identified together with the
identification of congestion at the access level would expectedly limit
the deployment time. i see a need to document this approach in the
context of this effort.

> For such a class i think the existing
> exp bits in MPLS, inertia, technical problems, and so on. 

see above.

> effort class,

how long this one would take - not sure we got a clear answer during the
BoF ? and how trustable this solution would be ?
 
-d.

---

From: David R Oran <[email-masked]>
Date: Thu, 31 Jul 2008 14:06:48 -0400

I think we can exploit both a scavenger DSCP and different congestion  
control in the endpoint as long as the the interaction between the two  
is understood and the combination works as well or better than either  
alone. That allows incremental deployment to have a decent utility  
function, and incidentally may allow better instrumentation by making  
visible the usage of the changed congestion control in the positions  
of the network that don't over-write non BE dscps.

DaveO.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 31 Jul 2008 14:20:48 -0400

Part of the problem is that DiffServ was never completely specified,  
in that there were no standard DSCP values to make deployment feasible  
at the consumer level. Plus, the problematic combination of VoIP + P2P  
is relatively new. Also, as far as I know, DiffServ is deployed in a  
number of more closed networks.

> RFC3662 was published five years ago. Even assuming slow adoption,  
> we should have heard from some operators that use it by now. I'm not  
> aware of any deployment.
>
> I agree that universal deployment of DiffServ scavenger service  
> would be the better solution, but it looks unlikely it will happen.  
> A transport-level solution that approximates what the DiffServ  
> solution would give us, but with a different (better?) incentive  
> angle, seems attractive.
>
> Lars

---

From: Bob Briscoe <[email-masked]>
Date: Fri, 01 Aug 2008 00:46:01 +0100

Henning, etc

Yes, access is the pinch point (and interconnect).

But your facts aren't quite right on DSL...
The user's own DSL upstream access is certainly a bottleneck (so 
you'd just have to buy a home hub that does Diffserv). But there's 
absolutely never any congestion on the shared upstream backhaul 
(because it's symmetric but fed by the asymmetric access).

However, a combination of file-sharing traffic and provisioning with 
contention makes the downstream DSL backhaul of many providers show 
persistent loss rates (0-2% peaking at 3% somtimes) throughout the 
'day' (08:00-24:00 ish). To add Diffserv would require configing it 
in the downstream queues of the remote access server (BRAS).

Regarding vendor support for Diffserv on BRASs, many support it, but 
most vendors offer fairly limited numbers of queues and you may find 
all the queues are already used for other scheduling stuff the 
provider has already put in (weighted fair queueing between ISPs 
sharing the BRAS, video services, VoIP etc). IOW, there's already a 
lot of scheduling stuff done in access networks - much of it is 
Diffserv-based - ie driven by internally generated DSCPs - but much 
is just nailed up by the provider config locally on the link in question.

BT have been drawing up plans for a scavenger class on the most 
congested links I mention above for the last few months, but that's 
not an official customer promise or anything. Just internal design 
work that may get taken up as a product, or may not. Initially it's 
unlikely to have a customer-controlled interface.

On backbones, it's an absolute certainty that any DSCP set for one 
network would currently be cleared by the next.

There's been pre-standards inter-provider DS activity around VPNs for 
some time much of which could be re-used for scavenger. Dave Clark 
pulled it together to try to bridge the impasse that DS had got to. 
Bruce Davie was the co-chair of the w-g. The idea was to put it all 
in this white paper:
<http://cfp.mit.edu/docs/interprovider-qos-nov2006.pdf>
then go off and put the different parts into the appropriate 
standards bodies. This has been happeneing (e.g. inter-provider SLA 
metrics in the ITU etc).

Here's my brief 3pp comparison of the issues between doing scavenger 
in the host and in the network, that I mentioned this afternoon:
"Solving this traffic management problem... and the next, and the next"
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#p2pi-solutions>

The main issue for DS is of course the interface with hosts. But also 
that networks have to add policing to BE once BE is better than 
something else. But everyone's guessing when they work out how to do 
this, because they can't use traditional Diffserv token bucket 
policing for residential customers - the traffic isn't aggregated 
enough. So it's all volume limits and arbitrary stuff being bandied about.

However, I've also tried to show that it's not all downhill for 
host-based scavenger either, tho I think it has more chance of 
getting there first (in a sense it already has with DNA) but I 
predict issues we haven't seen yet, which is why TANA is right to at 
least aim to document the issue as a whole.

Does anyone know what the status of the background service is in 
3GPP? It's been in the specs along with EF, AF & BE for some time 
(see ref in my p2pi position paper above).

Bob

>>>configured) ... then i think this would be a good short and long

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Fri, 1 Aug 2008 09:53:59 +0200

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Bob Briscoe
> Sent: Friday, August 01, 2008 1:46 AM
> To: Henning Schulzrinne
> Cc: [email-masked]; Toerless Eckert
> Subject: Re: [p2pi] DSCP or not
> 
> Henning, etc
> 

previous post correctly point that in the upstream direction the
bottleneck is on the first mile access link. in the downstream direction
and considering a pure distribution tree the (main) bottleneck is on the
link toward the aggr. network of the edge router playing the role of NAS
(see
<http://www.ietf.org/internet-drafts/draft-ietf-ancp-framework-06.txt>
for inst.) since distribution of traffic can only have a lower
granularity down the tree.  
 
note: access contains the first mile and the metro-access for aggr. if
you consider the figure you made use in your previous pointer you have
simplified that aggr. network to a backhaul link. while multiple aggr.
nodes may be comprised. note also that these network are progressively
becoming more meshy.

> sharing the BRAS, video services, VoIP etc). 

what do you call a "fairly limited" number of queues ? per subscriber
and per traffic class queuing are available on such devices. access
nodes can also provide for the same capability (using e.g. VLAN per
subscriber). the main point will be to consider a representative
baseline scenario for this type of exercise.

> IOW, there's already a 

The key question is what will be the boundary of the DS domain and
whether we will see or not (re-)classification and re-marking at the AN
even when the CPE is performing the job. if this is the case then which
MF classification should be used. 

> enough. So it's all volume limits and arbitrary stuff being 

the exact reason why you have an aggregation network in between. now
this does not prevent the use of DS at these boundaries.

> least aim to document the issue as a whole.

i agree but the assumption made when documenting these issues shall be
representative - caricaturing and limiting capabilities of access
networks as they used to be, would not be of any help.

-d.

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 1 Aug 2008 04:28:31 -0400

We haven't given up on the scavenger class either, although obviously our technical challenges are different than Bob's. :)

________________________________

From: [email-masked] on behalf of Bob Briscoe
Sent: Thu 7/31/2008 7:46 PM
To: Henning Schulzrinne
Cc: [email-masked]; Toerless Eckert
Subject: Re: [p2pi] DSCP or not

Henning, etc

Bob

---

From: ext Toerless Eckert <[email-masked]>
Date: Thu, 31 Jul 2008 10:10:53 -0700

> would give us, but with a different (better?) incentive angle, seems  

It's all a matter of market driver. DiffServ was added to networks
for voice. The more successfull the workaround (in single DSCP class)
is for preprovisioning/download traffic (p2p or not), the less pressure
is there to adopt a real DSCP solution. But as long as nobody
can prove the workaround can work as well as real DSCP separation,
it logically should not be the IETF standards solution, right ?
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 31 Jul 2008 11:21:11 -0700

> of the network that don't over-write non BE dscps.

Right. The first thing to validate is the presumption that
a conservative algorithm for p2p within the best-effort class
would not leverage spare bandwidth as good as a more aggressive
scavenger algorithm can in the presence of a real scavenger dscp class.

If we can easily show this, then the dual-approach i think
is justified. If we can't then a scavenger dscp class is not justified.

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 31 Jul 2008 12:33:02 -0700

> >manage transmission slots on the uplink based on DiffServ, however.

The upstream scheduler on the CMTS schedules packets on the
upstream from multiple CMs. This is not a DSCP aware process.
On the CM you can in the upstream direction to DSCP to queue
mapping like eg: on any router, based on DSCP, etc.., but this does not
interact with the upstreams cheduler.

If you set up docsis service flows then these will impact the total
amount of bandwidth the particular CM gets from the scheduler,
But to me those service flows are really more like intserv (per flow
admission control).