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

From: "Gunn, Janet" <[email-masked]>
Date: Wed, 20 Nov 2002 11:56:11 -0500

-----Original Message-----
From: RJ Atkinson [mailto:[email-masked]]

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

JPG-
I am certainly willing to agree that the primary problem is not in the core
of the major ISPs.  In fact, I THOUGHT that had been accepted at the interim
meeting this spring (not necessarily agreed to by everyone, but accepted
that it wasn't the issue we needed to address at this point).  The primary
problem seems to be in the access links, in gateways,  in small (typically
private) networks, and in "islands" of IP that are NOT part of the "Big I"
Internet (though the Internet protocols are still applicable), such as
within landline and mobile telecom networks. 

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

JPG- 
Yes, it is very encouraging that a mechanism exists.

Maybe one way of putting it is that WHERE such mechanisms exist, it would be
nice to have a uniform way of indicating "authorized" emergency (as opposed
to 911) traffic.  It would seen to me that a "label" somewhere in the TCP/IP
protocol stack would be the simplest way of providing a UNIFORM indication
(even if the labeled traffic is treated differently by each proprietary
mechanism).  If there is no uniform label, there would need to be a separate
label for each mechanism, and a method for recognizing/translating labels.
Which would increase the cost and complexity for everyone  

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

Several times, people have suggested that "the problem" is better addressed
either at the application level or the link level (both of which
conveniently take it out of the  domain of IETF).

First, as a general principle, I am always suspicious when one group says
"they" (another group/layer/technology) can solve the problem better than
"we" can.  This is often a result of understanding "our" stuff better than
we understand "their" stuff.  When asked, "they" often say that "we" can
address the problem better than "they" can.

Second, even if their IS a good solution (or several good solutions) at the
link level, the link level is not the same end-to-end.  There needs to be an
end-to-end way of IDENTIFYING the traffic that is entitled to "special
treatment".  It still seems to me that the TCP/IP protocol stack is the
"right" place  for this identification. 
_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 20 Nov 2002 18:14:01 -0500

On Wednesday, Nov 20, 2002, at 11:56 America/Montreal, Gunn, Janet 
> Which would increase the cost and complexity for everyone

A significant challenge with having a "uniform label" that is 
transmitted
inter-domain is that it creates a new, large DDOS vulnerability.

That aside for the moment, the *policy* applicable to the customer-side
router on a given access link is generally the exclusive and local 
policy
decision of the customer on that link.  The policy on the ISP-side 
router
of a given access link is generally the customer's policy, but probably
within some ISP-specific constraints (e.g. see Sprint's web page for one
example of such constraints).

In short, since the access customer is paying for the link, it is their
policy choice for CoS/QoS on their links.

> address the problem better than "they" can.

Thanks for sharing the perspective.  It is helpful to understand 
alternate
perspectives.

> "right" place  for this identification.

Proposals for end-to-end QoS should start by talking about how 
deploying them
inter-domain will avoid creating a very large new DDOS vulnerability.  
A huge
advantage of link-layer or link-specific (e.g. Sprint's CoS) QoS is that
it generally does not create such a DDOS vulnerability for the ISPs.

Ran
[email-masked]