Subject: Re: [Ieprep] The world's biggest data consumers don't think priority is such ...

From: RJ Atkinson <[email-masked]>
Date: Wed, 1 Oct 2003 10:17:34 -0400

Earlier, Ran Atkinson wrote:
>> Those folks
>> further say that the US DoD JCS has *prohibited* deployment of
>> prioritisation in DoD IP networks (unless a JCS waiver is obtained;
>> DISA network ops folks tell me they do not have such a waiver).

On Tuesday, Sep 30, 2003, at 23:55 America/Montreal, [email-masked] 
wrote:
> The words in the above statemet seem to have been jumbled. To correct
> the word order: The JCS has prohibited further deployment of IP 
> networks
> (for mission critical communications) until the necessary 
> prioritization
> is possible. They do not have such a waiver.

Thanks.  I checked again.  I am told that both statements (mine at top &
yours just above) are true.  It is helpful of you to clarify
by adding the second statement.

> I don't think that the "ops folks" are the ones to be telling you what
> the requirements are for the future.

Certainly there are many folks that might have an impact on the future.

The "ops folks" are in a very good position to speak to the present
deployments -- and my comment was a follow-up to James M Polk's
claim that "The US Gov and others already employ priority networks;".

Now I believe James' claim is true, at least for some USG networks,
primarily since the USG is so large that it rarely has a unified 
position
on anything and it has lots of different networks.  However, I thought
it worth clarifying that the JCS prohibition means that the DISA IP
networks (specifically {N,S}IPRnet) are not among the USG networks
that "already employ priority networks".  So not all USG networks
"already employ priority".   To me the situation seems a bit odd,
since the old DDN used the IP ToS byte as originally defined,
at least in some places within the network (e.g. using Proteon routers).

IMHO, in a lot of ways, the reported JCS prohibition on IP 
prioritisation
seems unfortunate, though no doubt they have good reasons, because 
various
mechanisms (e.g. DiffServ) can be very useful within a single 
administrative
domain -- and uplink bandwidth is really scarce in a lot of current 
field
operational environments (e.g. AF, IQ, ships at sea, aircraft in 
flight).

I'll further note that I think of IP QoS as something that is just
as useful for non-voice applications as for voice applications.
It isn't clear to me which meaning for "communications" is intended
in the statement you added, whether that is specifically voice,
or is any form of communications.  Perhaps that distinction isn't a key
issue for this IETF WG, however.

> I think they tend to think and
> concern themselves with what is currently in use. You need to talk to
> the standards people and those planning the future networks.

Agree.  I also talk with folks planning the future networks --
for example some of the many folks involved with DISA GIG-BE
and other projects.  And I will note that the GIG-BE RFP sought
equipment that supported a variety of QoS mechanisms at different
protocol layers and in different technologies.

Thanks,

Ran Atkinson
[email-masked]

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

---

From: Rex Buddenberg <[email-masked]>
Date: 01 Oct 2003 10:12:33 -0700

> protocol layers and in different technologies.

Diffserv works essentially identically to the old JANAP 128 precedence
indicator handling procedures (flash, immediate, priority, routine). 
That priority handling system exists today in Autodin (no, it still
hasn't gone away) and in the say JANAP 128 messages are handled (at
least in theory) ... which also still hasn't gone away.

The distinction here is a provisioning issue.  If you can overprovision
the network, then we have had ample discussion here that the
prioritization (e.g. diffserv) cures are worse than the disease.  GIG-BE
is a significant change in DISA economics (from fee-for-service to a
growth capitalization) which will probably result in overprovisioning
FOR THAT SEGMENT OF THE COMMS SYSTEM.  But that segment is never the
complete comms system -- DISA's infrastructure never touches the soldier
in the field or the sailor on the ship -- those segments are always
service-owned and operated.  

But the military comms system has bottlenecks in it that cannot be
wished away by throwing money into the overprovisioning budget.  For
several years these bottlenecks would show up in random places because
the investements are uneven.  But over the long term, the bottlenecks
are always in the radio-WAN.  The largest pipes (which are ironically
called 'High Speed Data' by the vendor) onto the typical Navy destroyer
have a capacity of 64kbps.  The terrestrial WAN at the commsta end of
this pipe can easily be provisioned at orders of magnitude greater
capacity.  And the Navy has provisioned its ships afloat at orders of
magnitude greater capacity (increasingly gig ethernet).  
	I notice that the Transformational Comms System briefings have had
'make bandwidth go away as a constraint' disappear -- apparently
somebody finally got a clue that the satellite capacities will always be
orders of magnitude less than the terrestrial.  

You can cut 'military' and past 'emergency services' in the above
paragraph and get the same situation.

The obvious lessons here are:
	- overprovision when you can.  Best way to do that is to up your Ao
numbers by getting diverse altroutes ... you'll find yourself
overprovisioning by accident.
	- the radio-WAN segment is one where overprovisioning is not practical
-- we need some kind of control mechanism.  Diffserv is one reasonable
avenue, access control is another -- both are hard to do in a highly
decentralized system that the internet is.  How do we get there without
generating a lose-lose situation?

-- 
b

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 01 Oct 2003 11:19:04 -0500

At 10:17 AM 10/1/2003 -0400, RJ Atkinson wrote:

>On Tuesday, Sep 30, 2003, at 23:55 America/Montreal, [email-masked] wrote:
>

I don't know why you took the statement quoted above to mean *ALL* networks 
within the US Gov....

>primarily since the USG is so large that it rarely has a unified position
>"already employ priority".

Can you find any quote where I stated "all (anything)"?

I didn't think so

>IMHO, in a lot of ways, the reported JCS prohibition on IP prioritisation
>seems unfortunate, though no doubt they have good reasons, because various
>mechanisms (e.g. DiffServ) can be very useful within a single administrative
>domain -- and uplink bandwidth is really scarce in a lot of current field
>operational environments (e.g. AF, IQ, ships at sea, aircraft in flight).

Diffserv can't preempt a session as JCS's requirements currently state 
needs to happen for MLPP functionality... please read *why* the prohibition 
was made and the waiver necessary before commenting on it.

You're uninformed about this area, which is sad.... and your comments are 
making that fact more apparent.

BTW -- I will eat one acronym I did state incorrectly. My fast fingers 
added "IP" to my original response to Sean's email and I knew that was not 
accurate just after I sent it. I know that error contributed to part of 
this rathole

>[email-masked]

cheers,
James

                                *******************
                 Truth is not to be argued... it is to be presented

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 1 Oct 2003 13:15:35 -0400

On Wednesday, Oct 1, 2003, at 12:19 America/Montreal, James M. Polk 
wrote:
> I don't know why you took the statement quoted above to mean *ALL* 
> networks within the US Gov....

Your statement was ambiguous.  I thought additional clarity
would be useful.  Clearly your mileage varies.  Enjoy.

> Can you find any quote where I stated "all (anything)"?

Please see above.

> needs to happen for MLPP functionality... please read *why* the 
> prohibition was made and the waiver necessary before commenting on it.

I am familiar with both.

It is not at all clear that DiffServ is unable to preempt.  I know
of deployments of IP ToS/DiffServ where the low-precedence IP traffic
is dropped and pre-empted by the high-precedence IP traffic --
because the network was configured to do just that.  There are some
reports by DoD components with test results that are not inconsistent
with this claim.

Among the keys to those successes were:
	- policing the markings so one avoided "precedence creep"
		(see postings from Rex Buddenburg et alia on this list);
	     this is often most easily done in edge switches, though
	     that can increase the deployment complexity.
	- marking network control traffic as highest priority, so that
	 	the network would not collapse due to user traffic pre-empting
		critical control traffic (e.g. routing protocols, bridge
		protocols).
	- ensuring that MLPP was really the policy that the network
		operator wanted to deploy on their network.
	- keeping the deployment within a single domain, so that the
		(D)DOS risks could be managed to level acceptable to the
		network operator

I'd be interested to hear the specifics of what other folks think is
needed beyond DiffServ (in the intra-domain deployment context).
That might be a way to focus discussion in a productive way.

> You're uninformed about this area,

Untrue.
I am informed; I've just reached different conclusions than you have,
probably because I have different data than you do.

The value of this list and the conversations here are the opportunities
to discuss things and for everyone to collect more data and maybe even
converge opinions.

Calling someone else uninformed isn't terribly likely to help either
put more data out or converge opinions; sigh.

> and your comments are making that fact more apparent.

Here we disagree, but please do enjoy your opinion. :-)

> added "IP" to my original response to Sean's email and I knew that was 
> not accurate just after I sent it. I know that error contributed to 
> part of this rathole

Thanks.

Ran Atkinson
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 1 Oct 2003 13:26:44 -0400

On Wednesday, Oct 1, 2003, at 13:12 America/Montreal, Rex Buddenberg 
wrote:
> But that segment is never the complete comms system -- DISA's
> infrastructure never touches the soldier in the field or the
> sailor on the ship -- those segments are always service-owned and 
> operated.

Agree.  However, all of the segments (DISA + service-specific
+ other DoD) can be considered to be a single administrative domain
for policy purposes, since a common policy can be decided upon
by SECDEF (or designee like ASDNII) and then deployed department-wide.

> wished away by throwing money into the overprovisioning budget.

(also links that the DoD chooses not to spend money on; both reasons
drive the ongoing existence of bottlenecks :-)

> But over the long term, the bottlenecks are always in the radio-WAN.

Yes.

> The largest pipes (which are ironically

Yes.

> orders of magnitude less than the terrestrial.

Right.

> 	- the radio-WAN segment is one where overprovisioning is not practical

s/not practical/often not practical/

> generating a lose-lose situation?

Good questions.

I think the answers are a lot easier intra-domain than inter-domain.

Intra-domain, one can deploy both DiffServ (or IP ToS with JANAP-like
markings) (optionally also link-layer precedence, such as 802.1p) and
also access controls.  This requires non-trivial effort in designing the
right controls/markings, getting the relevant network kit configured
appropriately, and getting the network monitoring systems in place
to monitor the network appropriately.   I've seen this done,
so I believe it is do-able.

I'd be interested to know what specific capabilities folks think we
need beyond what we have in hand (e.g. DiffServ, IP ToS, 802.1p).

Thanks,

Ran Atkinson
[email-masked]