[Iccrg] [budden@nps.navy.mil: [Fwd: Re: [Rmt] review solicitation for ICCRG congestion controlsurvey]]

[Wesley Eddy]

Here are some interesting comments that Rex Buddenberg asked me to relay
to the list in response to the solicitation for comments on
draft-irtf-iccrg-cc-rfcs-00.  He isn't on the ICCRG list, so you may
wish to copy him on replies.

----- Forwarded message from Rex Buddenberg <budden at nps.navy.mil> -----

Subject: [Fwd: Re: [Rmt] review solicitation for ICCRG congestion controlsurvey]
From: Rex Buddenberg <budden at nps.navy.mil>
To: weddy at grc.nasa.gov
Date: Fri, 12 Jan 2007 11:52:50 -0800

-------------------snip----------------------------------

My first read of your ID is that you've excluded a couple critically
important issues.  (The good news is that you recognized several end
systems self-contained issues that are indeed local).

For instance:
>We specifically do not include the vast amount of quality of service
>   (QoS) work into the scope
is a statement that I find confusing.  If there were no congestion, we
would need no QoS control.  And the congestion control problems are
manifested at the same place that the QoS controls are applied -- at the
routers.  
     (If all you mean by this exclusion is saving the labor of
recapitulating the QoS Control literature, fine.  But the two subjects
of congestion control and QoS are inseparably intertwined).  

First a scenario.  It is real-world in parts of the military today
(especially the Navy) but will become more so in all the services.  And
the military view is several years ahead of the common civilian
perception:

(Terrestrial-WAN).  Today we have a Defense Information System Network
that mimics commercial ISPs ; the Global Information Grid - Bandwidth
Expansion program upgraded the backbone to multi-homed, OC-192,
backbones to ~90 points of presence around the world.  It's
overprovisioned.  And it's able to continue to be overprovisioned for
the forseeable future by adding more commercially-available plumbing.  

(Mobile platforms).  Navy ships all have ethernets installed in them.
All combatants have at least 100BaseT backbones.  Again overprovisioned,
and it's easy to upgrade them -- the technology is commercially
available.

(Radio-WAN).  Both communications stations ashore and every radio room
afloat have routers in them today.  There are several ship-shore links
that have been jammed into square holes between these routers -- some
better and some worse.  Specific technology arguments aside, this
ship-shore link is four orders of magnitude less capacious than the rest
of the internet.  And this disparity will remain forever.  

This scenario is specific to the US Navy, but in slightly less mature
forms we see it elsewhere in the military and we see it in disaster
relief and emergency services situations.  There's nothing
military-unique or government-unique here.  

</specific scenario>

Comments:

  - the radio network (hereinafter radio-WAN) is not at the fringe of
the network (like WiFi); rather it's in the interior -- there's at least
one router between this radio-WAN and any end system.  (This voids any
contention access radio networks out of the application, but scheduled
access technologies like 802.16 fit nicely).  You can cartoon the
radio-WAN as a cloud with only routers at its border (no end systems).
  - the radio-WAN is surrounded by networks that are all of greater
capacity (by wide margins) than the radio-WAN is.  
  - the radio-WAN should be multicast; that's the only offset against
the capacity limitation ... and radio is inherently shared-media.
  - the congestion is manifested at the radio room/commsta routers -- at
the border of the radio-WAN.  This is also the point where QoS controls
have to be effected.
  - topologies are likely to be volatile so connection-oriented QoS
measures (like RSVP) are of little value.  
  - you should have little trouble extrapolating the scenario to
emergency services where a fire truck has a LAN supporting several
applications but is connected back to the fixed internet by a
bandwidth-limited radio-WAN.  (We have several disaster relief
real-world examples of this ilk).
  - 802.16, because of its scheduling MAC, has the ability to provide
QoS Control.  But the relationship between layer 2 QoS in .16  "Four
services (11.13.11) are supported: Unsolicited Grant Service (UGS),
Real-time pollinig service (rtPS), Non-real-time Polling Service
(nrtPS), and Best Effort (BE)." [IEEE 802.16-2004, SS 6.3.5] to layer 3
QoS (Diffserv) is not defined. 

Observations:

  - most of the IETF approaches to congestion control make some tacit
assumptions about underlying plumbing that are valid only in wired WAN
(terrestrial-WAN) situations: wired internets have point-to-point
plumbing at PHY (copper or fiber optic) meaning that there is no MAC and
consequently no QoS handles either available or necessary at layer 2.   
     But in radio-WANs  -- the critical place where we need QoS and
congestion control -- this all changes.   
  - congestion control is both a layer 3 and layer 2 problem.  Routers
can stack the packets up in appropriate order but they don't control how
the MAC gets access to the physical network.  
  (I agree with IAB's policy of staying out of layer 2-and-below issues.
In general, this is a wise policy, but we need to understand it's
limitations in treating congestion control and QoS issues). 
  - I don't see how congestion control can be disentangled from QoS
Control.  Not only do I want to control congestion at the radio
room/commsta routers, but that's also the control point where I need to
make sure the high priority stuff gets through.  The control point is
the same whether we are talking QoS or congestion control.  And there is
no point to QoS Control if there isn't any congestion.   
  - any fixes that apply only to unicast don't help much.  Unicast
should simply be treated as the trivial instantiation of multicast.  (I
like the building block approach in NORM).
  - trying to focus on a fix that is implemented only at end systems
puts you at the far end of a long screwdriver.  In fact, you have lots
of screwdrivers (every end system and every transport layer connection
within that end system) trying to control a problem that exists at a
much smaller set of routers.  Talk about trying to serve >1 master...

A couple (personal opinion) out-of-scope comments that are useful
background to this problem:

  - there have been several proposals for radio-WANs that overlap.  For
instance, the PAR for IEEE 802.22 reads very similar to that of 802.16:
both committees are to deliver both MAC and PHY (layer 2 and 1
specifications.  But the layer 2 issues are pretty much the same for
both target environments ... so I'm expecting that we'll probably see
the 802.16 MAC reused over a variety of PHY implementations tuned to
specifics -- much as we see many variants of ethernet over different
PHY.  
  - 802.16 MAC, with a bit of stretching, is applicable to long-latency
radio-WAN situations (like satellite comms systems).  Something _like_
the 802.16 MAC is necessary to break out of the point-point
straightjacket (circuit-switch blinders) that many satcom programs are
in now.  


What's the goal?

>ICCRG's goal to foster a long-term congestion control
>architecture for the Internet

I agree that this is necessary.

And I agree that a survey of the literature is a good start (indeed
there were a few you abstracted that I was not aware of).

But we need to do some serious thinking at the step immediately beyond
(what's usually termed 'agenda bashing' in IETF meetings.  The scenario
described above is, IMHO, a fairly general purpose one to start with.

Looking aft, a hippocratic approach of 'don't screw up what we have with
TCP' is ok.  But it is watching your wake.  

Help?

-- 
Rex Buddenberg
Naval Postgraduate School
Code IS/Bu
Monterey, Ca 93943

831/656-3576

----- End forwarded message -----