Subject: Re: [Ieprep] Re: Is QoS Dead?

From: RJ Atkinson <[email-masked]>
Date: Tue, 19 Nov 2002 12:13:46 -0500

Fred,

	Did you see the Sprint results presented yesterday by Dave Meyer that,
among other things, noted that the backbone traffic is NOT self-similar
above <specified> speed ?  I didn't see you in the room, but maybe that
was an oversight on my part.  I believe his presentation is available 
online
(maybe he can post the URL here ?).

	My memory is not perfect, but I think <specified> was around OC-12
in his presentation.

	Deploying QoS *in the core* seems unlikely to fix issues that 
fundamentally
live in the access links.  And Dave's presentation also described 
specific
interesting/useful approaches to improving the properties of access 
links
-- and those approaches do NOT require any IETF standards work, RSVP, 
DiffServ,
or NSIS.

Ran

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Fred Baker <[email-masked]>
Date: Tue, 19 Nov 2002 09:20:45 -0800

At 12:13 PM 11/19/2002 -0500, RJ Atkinson wrote:
>Deploying QoS *in the core* seems unlikely to fix issues that fundamentally
>live in the access links.

I'm at home (mostly) this week, for the first IETF meeting since Nov 1989, 
and at this instant writing from San Jose. No, I'll be interested to review 
his results.

I agree that the core is (at least mostly if not entirely) not at issue, as 
shown in the RIPE measurements etc; I do, however, refer you to Athina's 
paper and wonder what thoughts you might have.

My problem is that my traffic doesn't live only in the core - it goes end 
to end, through the cores of several networks, and through at least one 
access network that gives me fits. Telling me that the core has no problem 
doesn't convince me that my traffic will experience no problems. I can 
measure, and have given you pointers to graphic versions of those 
measurements, that this is simply untrue.

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 19 Nov 2002 12:48:03 -0500

On Tuesday, Nov 19, 2002, at 12:20 America/Montreal, Fred Baker wrote:
> My problem is that my traffic doesn't live only in the core - it goes 
> end to end,
> through the cores of several networks, and through at least one access 
> network that
> gives me fits. Telling me that the core has no problem doesn't 
> convince me that
> my traffic will experience no problems. I can measure, and have given 
> you pointers
> to graphic versions of those measurements, that this is simply untrue.

It would be pleasant (and seems to be the case) if we can simply agree 
here
that the primary problem lives in the access links, and hence the 
access links
should be the focus of efforts to improve service quality.

It would also be pleasant if we could agree that some mechanisms 
already exist
(referring specifically to the Class-of-Service implementation that Dave
Meyer outlined yesterday; see also the note from Sean Donelan that has 
the
public URL at sprint.net with the details) that do not use existing 
IETF standards
or need new IETF standards work.

Ran
[email-masked]

PS:	Entirely as an aside, the quality of DOCSIS cable modem 
implementations varies
significantly with regards to traffic shaping of packets (when either 
upstream
or downstream rate-limiting is in place).  At one time, a large 
operator systematically
tested these things and herded implementers to improve the quality of 
their
traffic shaping.  It is not clear to me whether anyone is 
systematically testing
this aspect of DOCSIS CMs these days.  My own cable modem, which has 
rate-limiting
similar to yours and is operating in an unfortunate upstream frequency 
range, seems
to behave a bit better than yours has been behaving.  This might be due 
to variance
in CM implementation or in CMTS implementation or other variables.

PPS:  DOCSIS specifications include support for a kind of link-layer 
QoS.  It is
likely that enabling/using that mechanism within that link type would 
be the most
successful approach to improving service quality on those kinds of 
links.  Note
that such link-layer QoS mechanisms don't require any IETF standards 
either.

---

From: David Meyer <[email-masked]>
Date: Tue, 19 Nov 2002 10:12:08 -0800

>> above <specified> speed ?  I didn't see you in the room, but maybe that

It looks like above OC12 (so 48 and above)

>> (maybe he can post the URL here ?).
http://www.maoz.com/~dmm/IETF55/ieprep

>> 	My memory is not perfect, but I think <specified> was around OC-12

Yes.

Dave

---

From: Fred Baker <[email-masked]>
Date: Tue, 19 Nov 2002 10:11:37 -0800

At 12:48 PM 11/19/2002 -0500, RJ Atkinson wrote:
>here that the primary problem lives in the access links, and hence the 
>access links should be the focus of efforts to improve service quality.

Within the United States, Australia, Western Europe, and parts of Asia, 
that is probably true. I was in Uganda last week... Bill Woodcock would be 
well qualified to discuss their networks, which use a bizarre mixture of 
tens of kilobits and unit gigabit links. Say VSAT, 802.11b, and so on.

>It would also be pleasant if we could agree that some mechanisms already 
>exist (referring specifically to the Class-of-Service implementation that 
>Dave Meyer outlined yesterday; see also the note from Sean Donelan that 
>has the public URL at sprint.net with the details) that do not use 
>existing IETF standards or need new IETF standards work.

If you're referring to DOCSIS, that's what I'm having to work around in 
Cox's network. Yes, link layer technologies exist that can change network 
behavior on those specific links; the change may be positive or negative, 
depending on to what purpose it is used, and is not end to end. If you want 
something end to end, I'm not prone to discuss link layer technologies.

---

From: David Meyer <[email-masked]>
Date: Tue, 19 Nov 2002 10:15:21 -0800

>> should be the focus of efforts to improve service quality.

This is the way I (we) see it.

>> or need new IETF standards work.

http://www.sprintlink.net/policy/cos_guidelines.html

Dave

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 19 Nov 2002 17:18:57 -0500

On Tuesday, Nov 19, 2002, at 13:11 America/Montreal, Fred Baker wrote:

>> already exist (referring specifically to the Class-of-Service 
>> implementation that Dave Meyer outlined yesterday; see also the note 
>> from Sean Donelan that has the public URL at sprint.net with the 
>> details) that do not use existing IETF standards or need new IETF 
>> standards work.
>
> If you're referring to DOCSIS, ...

No, I was referring to Sprint's CoS offering.  He just posted a URL for 
their
CoS offering in another email to this list.

I don't know whether Cox has enabled DOCSIS QoS (or even whether their 
deployed
CMTS and your cable modem support DOCSIS QoS).  My guess is that they 
have
not enabled DOCSIS QoS simply because it is a relatively new feature of 
DOCSIS.
Rate-limits were in DOCSIS 1.0.  QoS was not part of DOCSIS 1.0.  Most 
DOCSIS
deployed today seems to be based on 1.0, not 1.1 or 2.x.

Ran