FWD: SLUMS BOF

FYI

---------------- Forwarded  Message ----------------------

Received: from alpha.xerox.com ([13.1.64.93]) by louise.parc.xerox.com with SMTP id <358855>; Sun, 28 Feb 1999 10:03:35 PST
Received: from daffy.ee.lbl.gov ([131.243.1.31]) by alpha.xerox.com with SMTP id <52081(4)>; Sun, 28 Feb 1999 10:03:28 PST
Received: (from vern@localhost)
	by daffy.ee.lbl.gov (8.9.2/8.9.2) id KAA11122;
	Sun, 28 Feb 1999 10:03:26 -0800 (PST)
Message-Id: <199902281803.KAA11122@daffy.ee.lbl.gov>
To: ruts@lbl.gov
Subject: SLUMS BOF for addressing RUTS requirements
Cc: srini@watson.ibm.com, hari@lcs.mit.edu, spreitze@parc.xerox.com
Date: Sun, 28 Feb 1999 10:03:26 PST
From: Vern Paxson <vern@ee.lbl.gov>
X-UIDL: a3500b3e71e943e75d96aefa9dec3412
Status: U

There will be a BOF at the next IETF called SLUMS (= Support for Lots
of Unicast Multiplexed Sessions) that will explore possible transport
solutions to addressing a subset of the requirements that came out of
the RUTS BOF at the last IETF.  SLUMS is tentatively scheduled for
Wednesday (3/17) afternoon, 1PM-3PM.

The subset of the requirements we're picturing as in scope for SLUMS is:

    - quick establishment/activation, which is in tension with security
      considerations (authentication, flooding - not holding state)

    - support for application level framing:
        - control over reliability (e.g., setting time limits on how
	  long to try to deliver a message)
        - the ability to supercede previous application messages

    - minimize state requirements; think of servers with 1e6 connections

    - muxing: PDUs muxed, delivered ASAP.  Want ACK aggregation across
      the different communication streams; isolated flow-control; QoS
      consciousness between the streams.

    - congestion control across multiple communication streams

    - reducing slow start delays for multiple communication streams

    - failover: transport connection can survive across change in IP address
        - on connection attempt, SYN timeout are viewed as expensive
        - mid-stream, need to switch to backup interfaces

    - ability for application to indicate "a reply is coming" versus
      "no more coming now, go ahead and ack, don't delay"

And the ones that are not in scope:

    - support for application level framing:
        - visibility into network conditions
        - want to deal with transport at a 'frame' granularity (record marking)
        - per-message priority control

    - congestion control
        - slow start hit (bursty vs. even flow)
        - snappy after idle (bursty vs. even flow)
        - optionally becoming aggressive during loss (for control traffic
          whose job is to stem the congestion); e.g., FEC

    - small footprint

The goal of the BOF is to explore different basic approaches for addressing
these requirements.  All of the proposed approaches deal primarily with the
muxing requirement, ensuring that multiple communication threads between two
hosts obey the fundamental congestion control principles.  Addressing the
other requirements is generally deferred to higher-layer solutions, which
strikes us as a good way to divide up the problem.

Srini Seshan will discuss an approach that he, Hari Balakrishnan, and
colleagues have developed called the "Congestion Manager" (CM).  The basic
idea is that a host's different communication streams use a CM service to
determine when they can send and at what rate.  The CM is described in
the paper "An Integrated Congestion Management Architecture for Internet
Hosts", available from

	http://inat.lcs.mit.edu/papers/BRS99.ps

Please read this document if you have a chance - it's a very interesting
framework that has little overhead (none in the case of managing multiple
TCP connections).

Mike Spreitze will discuss MEMUX, which has come out of the HTTP-NG muxing
work.  MEMUX operates above the transport layer, multiplexing a set of
communication streams on top of a single transport connection.

We may also have advocates for integrating congestion control across
multiple TCP streams.  One can then implement lightweight communication
streams using multiple T/TCP connections.

- Vern & Scott



---------------- End of Forwarded Message ---------------

Received on Sunday, 28 February 1999 16:53:33 UTC