Subject: [Iccrg] Separate header checksums and WiFi
From: [email-masked] (Michael Welzl)
Date: Wed Jan 31 15:32:16 2007

Dear all,

A long time ago, at the San Diego IETF meeting in August 2004,
I presented an idea called "Corruption Notification Options"
(a proposal which is some sort of a refined specification of
the TCP HACK idea) to the TCPM group.

The group's feedback was that this is useless, as errors
occur in such a clustered fashion that you wouldn't see
any packets with an intact header but erroneous payload
(which is the only situation where the scheme would
yield any benefit). I think that it was Gorry Fairhurst
who said this.

I figured that the only convincing way to prove him
wrong is to actually do a real-life test. I did, and
proved him right  :)  that is, disabling checksums for
parts of packets doesn't yield much of a benefit in
WiFi networks, where it seems that frames are delivered
in an all-or-nothing fashion.

Doing this test requires patching the device driver (to
disable the link layer CRC), and above all, finding a good
student - all of this took quite some time, but now it's
over, and the documentation can be found at:
http://www.welzl.at/research/projects/corruption/
(bottom of the page)

I learned my lesson, and thought I'd share it with you -
but this result only concerns WiFi. I'll keep this as a
low-priority "background" project and may take a closer
look at other link layers one day... in any case, that
topic still interests me, and I can't believe that it
wouldn't be possible to get a benefit out of such a scheme.

I'm sending this note to TCPM, TSVWG and DCCP because there
are similar mechanisms there (DCCP: the Data Checksum option; SCTP:
http://www.ietf.org/internet-drafts/draft-stewart-sctp-pktdrprep-06.txt
although I just noticed that this is apparently not a WG item...
still, it's SCTP related).

This note also goes to ICCRG, because I think that this should
be the place for related discussions (in fact Lachlan Andrew
will give us a related talk at our upcoming meeting:
http://www1.tools.ietf.org/group/irtf/trac/wiki/Agenda )

Cheers,
Michael

From: [email-masked] (Aaron Falk)
Date: Sat Jan 27 03:39:44 2007
Subject: [Iccrg] webcasting the ICCRG meeting Feb 12-13
Message-ID: <[email-masked]>

Hi folks-

ISI has the facility to webcast the ICCRG meeting on Feb 12-13 but we  
the equipment needs to be manned during the meeting.  We need a  
volunteer (great task for a student).   Please send me a note if you  
are willing to do this or have someone you can volunteer. :)

--aaron

From: [email-masked] (Wesley Eddy)
Date: Fri Jan 12 21:07:12 2007
Subject: [Iccrg] Re: [Tsvwg] review solicitation for ICCRG congestion control survey
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Fri, Jan 12, 2007 at 12:33:14PM -0800, Erblichs wrote:
> 
> 	New item: Secondly, can I suggest a different per RFC layout.
> 	In my opinion, each RFC listing item should include the type of RFC,
> 	the date, the first author, and then the abstract. To give a
> 	different summary than the abstract is inconsistent to what was
> 	initially published for the RFC,IMO.

I can explain some of the logic for the current format, but to be clear,
I don't have any format preference as long as it's useful to readers:

(1) The type of RFC was left out because in certain sections, it ends
    up that all the documents are Informational, and in others all of
    them are Standards Track or all are Experimental.

(2) Author names were left out because they're in the References section
    at the end of the document anyways.  Personally, I'd rather see the
    name of the working group that produced the document, or whether it
    was an individual submission, or an IAB document, etc, than the author's
    name.

(3) Some of the full abstracts were often left out because some are
    rather long due to containing a lot of introductory statements that
    don't add much in the context of our document.

(4) I think giving a different summary than the abstract is *very* useful
    in some cases because sometimes it lets the reader know how the document
    has held up over time.  We probably haven't done it enough in the 00
    version, but it's often useful to know that certain RFCs have not really
    been widely implemented (e.g. RFC 3124, to pick on one).  We might also
    mention the controversy regarding ECN nonces in the entry for RFC 3540,
    for another example.  I notice we don't have much of this kind of
    supplemental (and more interesting) information in the document yet,
    but maybe RG participants can provide more juicy summaries for particular
    documents when they review the list.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

From: [email-masked] (Wesley Eddy)
Date: Fri Jan 12 20:13:52 2007
Subject: [Iccrg] [[email-masked]: [Fwd: Re: [Rmt] review solicitation for ICCRG congestion controlsurvey]]
Message-ID: <[email-masked]>

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 <[email-masked]> -----

Subject: [Fwd: Re: [Rmt] review solicitation for ICCRG congestion controlsurvey]
From: Rex Buddenberg <[email-masked]>
To: [email-masked]
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 -----

From: [email-masked] (Michael Welzl)
Date: Fri Jan 12 18:50:40 2007
Subject: [Iccrg] Wes Eddy to co-chair ICCRG
Message-ID: <00c601c7367a$5bdc6930$0200a8c0@fun>

Dear all,

Wes Eddy will be co-chairing the Internet Congestion Control Research  
Group.  We has been active in the IETF TCPM working group and will  
bring additional IETF awareness to the RG (which is expected to take  
a more active role in reviewing congestion control proposals prior to  
IETF consideration).  S. Keshav, the current ICCRG co-chair, will be  
stepping down due to lack of cycles.

Wes works for Verizon as an on-site contractor at NASA's Glenn  
Research Center in Cleveland, Ohio.  His work at NASA is focused on  
developing new architectures for both space-based networking and  
civil air traffic control that migrate legacy systems into IP-based  
net-centric operations.  Before Verizon, he was a student at Ohio  
University,  and an intern at NASA.  He has worked on analysis,  
modelling, simulation, and real-world implementations of several  
standard and custom transport protocols, mobility mechanisms, and  
delay-tolerant networking protocols.  He is active in the IETF TCPM  
working group, and co-authored the working group's TCP Roadmap RFC  
(RFC 4614) and TCP SYN Flooding document, among other contributions.   
He has advised the International Civil Aviation Organization (the  
United Nations's air traffic control standards body) on the IETF  
process and on the status of the IETF's applicable mobility
solutions.

Keshav, thanks for your service.  Welcome Wes!

Cheers,
Michael

From: [email-masked] (Michael Welzl)
Date: Fri Jan 12 17:55:12 2007
Subject: [Iccrg] Meeting agenda for 12/13 Feb
Message-ID: <004801c73672$d9aace90$0200a8c0@fun>

Dear all,

The updated meeting agenda is below. Almost all speakers have confirmed
that they will be able to make it despite the date shift, so I guess that
the
agenda is pretty solid by now.

If an update is inevitable, I'll send it to this list.

IMPORTANT: if you haven't already sent me such an email in the past,
please send an email to Alba Regalado-Palacios ( [email-masked] ) if
you would like to participate in this meeting.

Also note that logistics details (as well as the most up-to-date version
of the agenda) can be found in our Wiki:
http://www1.tools.ietf.org/group/irtf/trac/wiki/ICCRG
Direct link: http://www1.tools.ietf.org/group/irtf/trac/wiki/Logistics

I'm looking forward to meeting you in Marina Del Rey!

Cheers,
Michael

==============================================

Monday 12. 2. 2007:
-------------------
08:30 - 09:00   Light breakfast
09:00 - 09:15   Welcome and agenda bashing
09:15 - 09:30   Michael Welzl: The current state of ICCRG
09:30 - 10:00   Keshav: What is congestion and what is congestion control
10:00 - 10:45   Jeremy Mineweaser: Congestion control in the Global
Information Grid (GIG)
10:45 - 11:00   Break
11:00 - 11:45   Tom Phelan: DCCP, TFRC and Open Problems
                in Congestion Control for Media Applications
11:45 - 12:15   Lachlan Andrew: Rate control with packet corruption
12:15 - 13:45   Lunch
13:45 - 15:15   Lars Eggert: The role of the IETF/IAB/ICCRG for
                already deployed non-standard TCP CC
15:15 - 15:30   Break
15:30 - 18:00   Discussion: What should the ICCRG be doing?

Tuesday 13. 2. 2007:
--------------------
08:30 - 09:00   Light breakfast
09:00 - 09:45   K. K. Ramakrishnan: LT-TCP: Loss Tolerant TCP
09:45 - 10:30   Ted Faber and Eric Coe: Congestion Control with Explicit
Feedback
                (XCP implementation experiences (Eric), and potential for
                incremental deployment (Ted))
10:30 - 10:45   Break
10:45 - 11:30   Doan B. Hoang: FICC-DiffServ: using CC as a QoS element
11:30 - 12:15   Bob Briscoe: Flow Rate Fairness: Dismantling a Religion
12:15           Open discussion: Next steps: meetings, docs, etc

From: [email-masked] (Michael Welzl)
Date: Fri Jan 12 07:21:36 2007
Subject: [Iccrg] Re: [Tsvwg] review solicitation for ICCRG congestion control survey
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Mitchell,

Thanks for your comments!

> 	Doesn't this document initially imply that ONLY
>    "feedback-based adjustment" type responses are available 
>    to ameloriate congestion.
> 
>     As congestion approaches, the lack of acks/feedback can
>    also indicate congestion. So I would first modify section
>    "1" to indicate that the loss of feedback is also a level
>    of feedback that needs to be considered.

Agreed. Indeed, the lack of feedback is a form of
feedback itself.

In the remainder of your email, you raised some interesting
research questions - but I don't think that our document
should address these, as our intention is not to provide
a discussion of all the design pro's and con's of
congestion control (which is an almost endless story).

For example:

>    In addition, this reader is unaware whether this document prefers
>    flows that are at the precipice of congestion or whether a
>    significant buffer of lost bandwidth should be used to minimize
>    any congestion type behaviours.

the draft doesn't prefer anything; it is merely
meant as a survey of what the IETF has done in
this area.

Of course, no such document can stand without some
introductory statements about the general field
that is being addressed - and therefore I fully
agree with your correction regarding section 1.

Cheers,
Michael

From: [email-masked] (Wesley Eddy)
Date: Thu Jan 11 15:57:52 2007
Subject: [Iccrg] review solicitation for ICCRG congestion control survey
Message-ID: <[email-masked]>

In the ICCRG's goal to foster a long-term congestion control
architecture for the Internet, its initial step is to understand all of
the current mechanisms in use.  As an aid to this, the ICCRG is working
on a document that summarizes all of the congestion control mechanisms
and other guidance that the IETF has produced and published in the RFC
series.  The initial version of this document is online:
http://tools.ietf.org/group/irtf/draft-irtf-iccrg-cc-rfcs-00.txt

We think this is a fairly complete listing of the RFCs that relate to
congestion control, but if you know of others that should be included,
we would like to hear about it.

Also, comments on what can be done to make this more useful or readable
are welcome.  Comments on and improvements to the text summarizing each
RFC are also welcome.

The goal is to gather these inputs before the ICCRG meeting in
mid-February.  After the ICCRG meeting, the document will be updated
based on these comments and discussion from the meeting.

Please send all comments to the ICCRG list ([email-masked]).  Although
this request is being sent to multiple lists, this is only to notify
people not on the ICCRG list; we do not want to burden the other mailing
lists with replies, so please trim the "to" and "cc" fields of replies.

Thanks in advance.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

From: [email-masked] (Michael Welzl)
Date: Fri Jan  5 08:59:44 2007
Subject: [Iccrg] ICCRG meeting shifted to 12/13 February!
Message-ID: <[email-masked]>

Dear all,

Due to a date conflict with a Microsoft meeting, our meeting
will be shifted to 12/13 February.

Everything else will stay as it was:
* the location will be ISI, as before (co-located with Pfldnet)
* the agenda which I posted previously (see
http://oakham.cs.ucl.ac.uk/pipermail/iccrg/2006-December/000162.html )
is still valid - and so is the call for input that I made! If
you have something to say which fits in the scope of the group,
drop me a line, give me a title.

Again, if you plan to attend (and haven't yet done so) send
me an email please.

Jitu: now that we avoided the conflict - why don't you attend
our meeting and give us a report on what happened at the
Microsoft meeting?

Cheers,
Michael