Subject: [Ieprep] Is this the service you are requesting?

From: "King, Kimberly S." <[email-masked]>
Date: Thu, 14 Nov 2002 14:43:16 -0500

Correct me if I'm wrong.  This is what I believe I am hearing from a subset
of the WG.

Potential Desired Service:
ETS service would like to contract with a set of ISP(s) and service
providers.  Any ETS user would access ANY point where any of those ISPs have
presence (even connect via an arbitrary company's LAN who has an access link
to one of those ISPs), be authenticated and get priority in applications and
*QoS* priority in transport, especially over the access link. 

Potential Optional Enhancement over the above heard from subset of WG:
Should traffic traverse more than one ISP, that QoS status should be
maintained.  

If this is correct, then we can discuss the issues surrounding this.  If
not, we still need to be more concrete about what is being requested.

Kimberly

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

---

From: Rex Buddenberg <[email-masked]>
Date: 14 Nov 2002 12:17:24 -0800

> Correct me if I'm wrong.  This is what I believe I am hearing from a subset

Well, not this subset.

First a reiterate: QoS is a condition measurable in terms of latency,
jitter, determinism and throughput.  QoS _control_ is a means of
optimizing some of these parameters at the expense of others.
</definition>
> *QoS* priority in transport, especially over the access link. 
The user needs a certain QoS.  How the ISP(s) deliver it is a different
story.  If one of the intermediate ISPs is able to deliver the QoS I
need through overprovisioning, that's ok.  And clearly, for some core
segments of the network that's probably adequate and it certainly
conforms to the KISS principle.  What I want from those ISPs is a
Hippocratic assurance that they won't mangle a DS byte along the way.
	At that point, these ISPs have done their job -- they've delivered the
QoS I need (and done it without any explicit QoS control).

> Should traffic traverse more than one ISP, that QoS status should be

If you amend "QoS status" to something like 'undisturbed labels', (to
fit Ken Carlburg's language), then I'm happy.  

Aside.  The reasoning here is that routers can and do manipulate parts
of the IP datagram header.  For instance if your router is running NAT,
network address translation, it will replace IP addresses in the
header.  And some routers (usually border ones) will manipulate the DS
byte -- core routers generally do not since they're too busy drinking
from OC-48 pipes to fiddle with such nuisances.  We want a QoS control
pass-through with fidelity.  
	For the SIP worriers, this is a no-nevermind, routers do not fiddle
with the contents of an IP datagram which is where any application layer
special handling indicators would lie.

Page Two:

Scott wrote:

> 
> the inability of the tail circuit to support the load could be 
> delt with by getting a fatter tail circuit or by handling packets
> differently on the narrow link

Fatter tail circuits are problematic -- radios and all. 
Overprovisioning gets hard.  Therefore, the phrase after 'or' is
operative.  But it need only be operative over the tail circuit*. If the
datagrams arrive at the routers surrounding the tail circuit, then we
have a local problem for which we can devise local -- not Internet-wide
-- solutions.  

I think this triage is fairly important, else we have non-scaleable
solutions.

*in at least the Navy's case, the narrow links are in the interior of
the network, not at the edge which the term 'tail circuit' implies.  We
can overprovision both ashore and within the ship but not in the
ship-shore area.

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 14 Nov 2002 20:20:27 -0500

On Thursday, Nov 14, 2002, at 15:17 America/Montreal, Rex Buddenberg 
wrote:
> What I want from those ISPs is a

It is not very likely that a DS byte will survive an inter-domain
boundary intact.  Most likely it will get rewritten to DS == 0,
since the originating user is not a directly-attached customer of
the 2nd ISP.

We have a (really great) DiffServ implementation in our boxen.
THe main request from ISPs was the ability to rewrite the DS
byte of all packets received on an interface to a value specified
by the ISP.  When I asked why they wanted this, universal answer
was "to reset the IP ToS byte to zero" on all inbound interfaces.

> And some routers (usually border ones) will manipulate the DS
> from OC-48 pipes to fiddle with such nuisances.

Yes and yes.

> can overprovision both ashore and within the ship but not in the

<humour>
Yeah.  They don't make spools of fibre long enough to stretch from
the pier at North Island to the carrier half-way to Pearl. :-)
</humour>

Ran

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 14 Nov 2002 20:35:51 -0500

RJ Atkinson wrote:

> since the originating user is not a directly-attached customer of

Just curious: If no "real" ISP is using DSCPs, why would they care what 
value they have when entering or leaving their network?

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 14 Nov 2002 20:53:53 -0500

On Thursday, Nov 14, 2002, at 20:35 America/Montreal, Henning 
Schulzrinne wrote:
> Just curious: If no "real" ISP is using DSCPs, why would they care
> what value they have when entering or leaving their network?

Not sure why they care about it.

Guess:	Defensive configuration of the network

Ran

---

From: David Meyer <[email-masked]>
Date: Thu, 14 Nov 2002 21:07:23 -0800

>> value they have when entering or leaving their network?

Because I might not honor the DSCP in my core, but I may on
egress (from my network).

Dave

---

From: David Meyer <[email-masked]>
Date: Thu, 14 Nov 2002 21:05:43 -0800

On Thu, Nov 14, 2002 at 08:20:27PM -0500, RJ Atkinson wrote:
>> boundary intact. 

Right, like P(survival) == 0 if I offer a service based on the DS byte
(since I have to wipe it on ingress).

Dave

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 15 Nov 2002 00:33:52 -0800 (PST)

> value they have when entering or leaving their network?

Because the consequences of QoS control (to use Rex's distinction)
occurring on a production network are so dire that precautions must be
taken to avoid acidentally triggering little bits of it which may be
active through misconfiguration, implicit defaults, or vendor bugs.

                                -Bill

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 15 Nov 2002 07:40:37 -0500

Are you saying your network is setting DSCP to a non-zero value for some 
packets? Otherwise, if you set all DSCPs to zero on ingress, there's 
nothing to honor on egress (since they'll all be zero anyway). I'm 
confused... Or are you keeping the DSCP of direct customers of yours?

---

From: David Meyer <[email-masked]>
Date: Fri, 15 Nov 2002 04:48:18 -0800

Let's see if I can clarify: If I have a service where customers
set (or I set for them) DSCP on ingress to my network, ingore
them in my core (becauses it doesn't matter there), then honor
them on egress (because that's where it matters), then I have to
wipe those  bits on every ingress (including peering links) that
doesn't subscribe to the service. Otherwise the service can be
stolen or DoS'ed (it can be anyway, but this is the minimin you
must do). 

Does this help?

Dave

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 15 Nov 2002 07:54:25 -0500

Yes, thanks - so it's "you need to pay to get those bits across" :-)

I suspect that the conclusion is that for resource control on access 
links, you'll effectively need per-flow reservation since incoming "high 
value" bits in all likelihood won't get the access link treatment you 
want. About the only case where it might work would be some form of 
same-ISP VPN.

---

From: Scott Bradner <[email-masked]>
Date: Fri, 15 Nov 2002 08:12:28 -0500 (EST)

> what value they have when entering or leaving their network?

because many ISPs do use these bits to prioritize routing & management traffic 
in their net and they do not want incoming traffic to get prioritized
and overload the routing & management packets - they can do this
because they do not have to worry that this type of traffic will ever 
be enough to overload links on its own (and if this traffic does
not go through the net does not work)

Scott

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 15 Nov 2002 21:43:33 -0500

On Friday, Nov 15, 2002, at 07:40 America/Montreal, Henning Schulzrinne 
wrote:

> Are you saying your network is setting DSCP to a non-zero value for 
> some packets? Otherwise, if you set all DSCPs to zero on ingress, 
> there's nothing to honor on egress (since they'll all be zero anyway). 
> I'm confused... Or are you keeping the DSCP of direct customers of 
> yours?

Consider that BGP packets are super-critical, that many routers 
automatically
mark BGP packets with the IP ToS setting of Internet Control, and that
BGP packets are inter-domain.

Might be strongly desirable to prefer the BGP packets to anything else 
on egress
to another network -- in the interest of availability, reliability, etc.

Ran