Subject: Re: [p2pi] DSCP or not

From: Bob Briscoe <[email-masked]>
Date: Sat, 02 Aug 2008 16:50:00 +0100

Dimitri,

At 08:53 01/08/2008, PAPADIMITRIOU Dimitri wrote:
> > -----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
> >
> > 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).
>
>previous post correctly point that in the upstream direction the
>bottleneck is on the first mile access link.

[BB] You & I are agreeing, but... The sentence of Henning's I was 
correcting was "...the important link limit in both cable and DSL is 
the uplink". I was pointing out (as you agree below) that downstream 
DSL backhaul is often congested too, and the upstream DSL backhaul is 
not congested at all.

>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.

[BB] Most certainly. I said I had only shown how the network looks to 
IP (logical not physical topology).

[BB] One big simplifaction I made was to show all the backhaul links 
to the BRAS as if they don't cross the core, whereas there's often 
point-point (L2 over L3) pseudowires from each DSLAM across the core 
to each particular ISP's own BRAS(s). But as the core segments of 
these links are rarely if ever congested, I simplified them out of the picture.

>note also that these network are progressively
>becoming more meshy.

[BB] Indeed. And the multiplexing helps reduce costs and therefore 
makes it cheaper to upgrade out of congestion ('resource pooling' if 
you saw Mark Handley's talk).

[BB] But wholesale business models still don't know how to sell 
capacity across a mesh without turning it into a load of nailed up 
pipes and losing the resource pooling gain. We have been sponsoring 
research on this, to extend the promising contract and balancing 
approach [Anderson06] from just shared links to a shared mesh.

> > [snip]
> > 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).
>
>
>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.

[BB] There's a wide range out there depending on which vendor and 
model the ISP or operator bought. Some only have enough queues to do 
per-ISP or per-service scheduling, while others have enough for 3 or 
4 per user. I really don't know all the details across the range, and 
I'd rather not start giving selective brochure stats on the models I 
know about, as the thread will just become a vendor beauty contest.

[BB] But if someone could give a wider range of product info than I 
know, that would be worth hearing - to get a better feel for what 
most ISPs would be able to do with their current equipment.

> > 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.
>
>
>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.

[BB] Yes. And whether DS markings will be copied down to the 
encapsulating lower layer for the large majority of current access 
equipment that isn't IP-aware, but could do scheduling (e.g. 802.1p).

> > [snip]
> > 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.
>
>
>the exact reason why you have an aggregation network in between. now
>this does not prevent the use of DS at these boundaries.

[BB] I'm sure it doesn't prevent using DS, but it does prevent 
re-using all the theory on which DS policing was built. The existence 
of an aggregation network doesn't solve the fact that /each 
customer's/ traffic isn't sufficiently aggregated to police 
separately as in all the theory built up for traditional DS policing 
where each single (enterprise) customers' traffic is sufficiently 
aggregated already.

> > 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.
>
>
>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.

[BB] Like you, I prefer to think about the future. But TANA seems 
very focused on only a few months away. In that case, there's a huge 
amount of access equipment  that isn't going to be obsoleted any time 
soon - this stuff represents the largest part of a residential 
operator's sunk investment.

[BB] Reference:
[Anderson06] Edward Anderson, Frank Kelly and Richard Steinberg, "A 
Contract and Balancing Mechanism for Sharing Capacity in a 
Communication Network," In: Management Science 52 pp. 39--53 (2006).

Bob

>-d.

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

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

---

From: Stanislav Shalunov <[email-masked]>
Date: Sat, 2 Aug 2008 11:11:55 -0700

This is a TANA discussion and should for now be on tsv-area.

The real challenge in deploying scavenger is not even the core, which  
is infrequently congested, but the very edge, which gets congested on  
every upload.  Many more devices (cable and DSL modems), most of them  
hard to manage en masse.

A practical solution, therefore, must be end-to-end.  Whether to add a  
DSCP marking to the traffic is an orthogonal question, and the answer  
is likely positive, if we can find a suitable codepoint.  I expect we  
can, with 001000 being the most obvious candidate.

This will be particularly useful if networks would exclude scavenger- 
marked traffic from quotas, etc.

Since we can't rely on a network that does not support scavenger to do  
anything with scavenger traffic (including resetting the DSCP), having  
a negotiation that switches between algorithms is challenging.   
Consider that most head ends of congested bottlenecks are not even IP  
devices.

-- Stas

On Jul 31, 2008, at 7:37 AM, Toerless Eckert wrote:

>
> 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

--
Stanislav Shalunov

---

From: John Leslie <[email-masked]>
Date: Mon, 4 Aug 2008 11:49:11 -0400

It would appear Comcast is under a deadline:

http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-284286A1.pdf
] 
] Under the plan, within 30 days of release of the OrderComcast must: 
] - Disclose the details of its discriminatory network management
]   practices to the Commission 
] - Submit a compliance plan describing how it intends to stop these
]   discriminatory management practices by the end of the year 
] - Disclose to customers and the Commission the network management
]   practices that will replace current practices 

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

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 4 Aug 2008 13:35:11 -0400

I'm not a lawyer, and this is in no way, shape or form an official
statement by Comcast...  Just my individual / personal two cents.  

Check out http://www.comcast.net/networkmanagement/ as this contains
some relevant information...

Needless to say, our team is hard at work on the new, protocol-agnostic
network management technique.

Jason

> Behalf Of John Leslie
> Sent: Monday, August 04, 2008 11:49 AM
> To: [email-masked]
> Subject: [p2pi] Rock, meet Hard Place
> 
>