Subject: [Iccrg] List of CC RFCs and Internet-drafts
From: [email-masked] (Michael Welzl)
Date: Mon Mar 27 16:15:12 2006

Dear all,

At last, here are the RFC and Internet-draft references from
my book that are related to congestion control but not TCP
specifications.

I skipped everything that is related to traffic engineering
and QoS although this is also about handling traffic, albeit
on a different time scale and perhaps with a human
controller  :)   Seriously, depending on how broad we want
the document to be, some of these things could be looked
at - for instance, RFC 2990 contains some text about TCP
interactions with QoS elements.

I hope I didn't miss anything important. Note that the list
is from February / March 2005, which is when I submitted
the manuscript. I updated the draft references, but some
relevant ones are surely missing -
draft-ietf-tsvwg-ecn-alternates-00.txt, for example,
and also the IRTF draft draft-irtf-tmrg-metrics-01.txt.

Well, it's only a starting point - I hope the list is useful.

Cheers,
Michael

Documents that are also in the roadmap draft but might
be of general congestion control interest:
=======================================================

Border J, Kojo M, Griner J, Montenegro G and Shelby Z 2001 {Performance
  Enhancing Proxies Intended to Mitigate Link-Related Degradations} RFC
3135
  (Informational).

Link layer interaction:

Dawkins S, Montenegro G, Kojo M and Magret V 2001a {End-to-end
Performance
  Implications of Slow Links} RFC 3150 (Best Current Practice).

Dawkins S, Montenegro G, Kojo M, Magret V and Vaidya N 2001b {End-to-end
  Performance Implications of Links with Errors} RFC 3155 (Best Current
  Practice).

Fairhurst G and Wood L 2002 {Advice to link designers on link Automatic
Repeat
  reQuest (ARQ)} RFC 3366 (Best Current Practice).

Karn P, Bormann C, Fairhurst G, Grossman D, Ludwig R, Mahdavi J,
Montenegro G,
  Touch J and Wood L 2004 {Advice for Internet Subnetwork Designers} RFC
3819
  (Best Current Practice).

HighSpeed TCP - a TCP variant, but right now considered
a "special" TCP in the cc. research community as far
as I can tell:

Floyd S 2003 {HighSpeed TCP for Large Congestion Windows} RFC 3649
  (Experimental).

General architecture documents that are related to
congestion control via end-to-end arguments etc.:
==================================================

Carpenter B 1996 {Architectural Principles of the Internet} RFC 1958
  (Informational).
Updated by RFC 3439.

Bush R, Meyer D, {Some Internet Architectural Guidelines and Philosophy}
RFC3439,  December 2002   INFORMATIONAL
Updates RFC 1958 

RFCs of historic interest:
==========================

Mills D 1983 {Internet delay experiments} RFC 889.

Nagle J 1984 {Congestion control in IP/TCP internetworks} RFC 896.

Mankin A and Ramakrishnan K 1991 {Gateway Congestion Control Survey} RFC
1254
  (Informational).

Ramakrishnan K and Floyd S 1999 {A Proposal to add Explicit Congestion
  Notification (ECN) to IP} RFC 2481 (Experimental).
Obsoleted by RFC 3168.

Multicast:
==========

Handley M, Floyd S, Whetten B, Kermode R, Vicisano L and Luby M 2000a
{The
  Reliable Multicast Design Space for Bulk Data Transfer} RFC 2887
  (Informational).

Luby M and Goyal V 2004 {Wave and Equation Based Rate Control (WEBRC)
Building
  Block} RFC 3738 (Experimental).

Mankin A, Romanow A, Bradner S and Paxson V 1998 {IETF Criteria for
Evaluating
  Reliable Multicast Transport and Application Protocols} RFC 2357
  (Informational).

Speakman T, Crowcroft J, Gemmell J, Farinacci D, Lin S, Leshchiner D,
Luby M,
  Montgomery T, Rizzo L, Tweedly A, Bhaskar N, Edmonstone R,
Sumanasekera R and
  Vicisano L 2001 {PGM Reliable Transport Protocol Specification} RFC
3208
  (Experimental).

Whetten B, Vicisano L, Kermode R, Handley M, Floyd S and Luby M 2001
{Reliable
  Multicast Transport Building Blocks for One-to-Many Bulk-Data
Transfer} RFC
  3048 (Informational).

Widmer J and Handley M 2006 Tcp-friendly Multicast Congestion Control
(TFMCC):
  Protocol Specification. internet-draft draft-ietf-rmt-bb-tfmcc-06.txt,
work in
  progress.

DCCP:
=====

All drafts removed because they were outdated, but I'd say that
*everything* on http://www.icir.org/kohler/dccp/ belongs in this
document.

Everything else:
================

Balakrishnan H and Seshan S 2001 {The Congestion Manager} RFC 3124
(Proposed
  Standard).

Braden B, Clark D, Crowcroft J, Davie B, Deering S, Estrin D, Floyd S,
Jacobson
  V, Minshall G, Partridge C, Peterson L, Ramakrishnan K, Shenker S,
Wroclawski
  J and Zhang L 1998 {Recommendations on Queue Management and Congestion
  Avoidance in the Internet} RFC 2309 (Informational).

Floyd S 2000 {Congestion Control Principles} RFC 2914 (Best Current
Practice).

Floyd S and Kempf J 2004 {IAB Concerns Regarding Congestion Control for
Voice
  Traffic in the Internet} RFC 3714 (Informational).

Handley M, Floyd S, Padhye J and Widmer J 2003 {TCP Friendly Rate
Control
  (TFRC): Protocol Specification} RFC 3448 (Proposed Standard).

Ramakrishnan K, Floyd S and Black D 2001 {The Addition of Explicit
Congestion
  Notification (ECN) to IP} RFC 3168 (Proposed Standard).

Spring N, Wetherall D and Ely D 2003 {Robust Explicit Congestion
Notification
  (ECN) Signaling with Nonces} RFC 3540 (Experimental).

Gharai L 2005 RTP Profile for TCP Friendly Rate Control. internet-draft
  draft-ietf-avt-tfrc-profile-05.txt, work in progress.

Floyd S, Allman M, Jain A, Sarolahti, P 2006 Quick-Start for TCP and IP.
internet-draft draft-ietf-tsvwg-quickstart-02.txt, work in progress.

From: [email-masked] (Wesley Eddy)
Date: Wed Mar 22 21:52:00 2006
Subject: [Iccrg] iccrg status at IETF tsvwg meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, Mar 22, 2006 at 05:15:11PM +0100, Michael Welzl wrote:
> 
> For TCP beyond VJ algorithms, you could simply point to the
> Roadmap document of TCPM.

To save people from having to look this up and grep through the
document, here are the relevent extracts from the TCP Roadmap I-D.  It
is interesting to note that in constructing the TCP Roadmap, we found it
difficult to distinguish between congestion control and loss recovery
functions.  Some discussion of this follows in the pasted text.  In my
opinion, the relation between these two functions should be further
considered by the ICCRG.

In Section 2 - "Basic Functionality":
"""
   RFC 2581 S: "TCP Congestion Control" (April 1999)

      Although RFC 793 did not contain any congestion control
      mechanisms, today congestion control is a required component of
      TCP implementations.  This document [RFC2581] defines the current
      versions of Van Jacobson's congestion avoidance and control
      mechanisms for TCP, based on his 1988 SIGCOMM paper [Jac88].  RFC
      2001 was a conceptual precursor that was obsoleted by RFC 2581.

      A number of behaviors that together comprise what the community
      refers to as "Reno TCP", are described in RFC 2581.  The name
      "Reno" comes from the Net/2 release of the 4.3 BSD operating
      system.  This is generally regarded as the least common
      denominator among TCP flavors currently found running on Internet
      hosts.  Reno TCP includes the congestion control features of slow
      start, congestion avoidance, fast retransmit, and fast recovery.

      RFC 1122 mandates the implementation of a congestion control
      mechanism, and RFC 2581 details the currently accepted mechanism.
      RFC 2581 differs slightly from the other documents listed in this
      section, as it does not affect the ability of two TCP endpoints to
      communicate; however, congestion control remains a critical
      component of any widely-deployed TCP implementation and is
      required for the avoidance of congestion collapse and to ensure
      fairness among competing flows.
"""

Since computation of the RTT and guessing a reasonable RTO is an important
part of congestion control, I would also include:
"""
   RFC 2988 S: "Computing TCP's Retransmission Timer" (November 2000)

      Abstract: "This document defines the standard algorithm that
      Transmission Control Protocol (TCP) senders are required to use to
      compute and manage their retransmission timer.  It expands on the
      discussion in section 4.2.3.1 of RFC 1122 and upgrades the
      requirement of supporting the algorithm from a SHOULD to a MUST."
      [RFC2988]
"""

In Section 3 - "Recommended Enhancements" 
"""
   RFC 3168 S: "The Addition of Explicit Congestion Notification (ECN)
   to IP" (September 2001)

      This document [RFC3168] defines a means for end hosts to detect
      congestion before congested routers are forced to discard packets.
      Although congestion notification takes place at the IP level, ECN
      requires support at the transport level (e.g., in TCP) to echo the
      bits and adapt the sending rate.  This document updates RFC 793 to
      define two previously-unused flag bits in the TCP header for ECN
      support.  RFC 3540 provides a supplementary (experimental) means
      for more secure use of ECN, and RFC 2884 provides some sample
      results from using ECN.

3.1  Congestion Control and Loss Recovery Extensions

   Two of the most important aspects of TCP are its congestion control
   and loss recovery features.  Since TCP traditionally (in the absence
   of ECN) uses losses to infer congestion, there is a rather intimate
   coupling between congestion control and loss recovery mechanisms.
   There are several extensions to both features, and more often than
   not, a particular extension applies to both.  In this sub-section, we
   group enhancements to either congestion control, loss recovery, or
   both, which can be performed unilaterally - without negotiating
   support between endpoints.  In the next sub-section, we group the
   extensions which specify or rely on the SACK option, which must be
   negotiated bilaterally.  TCP implementations should include the
   enhancements from both sub-sections so that TCP senders can perform
   well without regard to the feature sets of other hosts they connect
   to.  For example, if SACK use is not successfully negotiated, a host
   should use the NewReno behavior as a fall-back.

   RFC 3042 S: "Enhancing TCP's Loss Recovery Using Limited Transmit"
   (January 2001)

      Abstract: "This document proposes Limited Transmit, a new
      Transmission Control Protocol (TCP) mechanism that can be used to
      more effectively recover lost segments when a connection's
      congestion window is small, or when a large number of segments are
      lost in a single transmission window."  [RFC3042]

      Tests from 2004 showed that Limited Transmit was deployed in
      roughly one third of the web servers tested [MAF04].

   RFC 3390 S: "Increasing TCP's Initial Window" (October 2002)

      This document [RFC3390] updates RFC 2581 to permit an initial TCP
      window of three or four segments during the slow-start phase,
      depending on the segment size.

   RFC 3782 S: "The NewReno Modification to TCP's Fast Recovery
   Algorithm" (April 2004)

      This document [RFC3782] specifies a modification to the standard
      Reno fast recovery algorithm, whereby a TCP sender can use partial
      acknowledgements to make inferences determining the next segment
      to send in situations where SACK would be helpful, but isn't
      available.  While it is only a slight modification, the NewReno
      behavior can make a significant difference in performance when
      multiple segments are lost from a single window of data.

3.2  SACK-based Loss Recovery and Congestion Control

   The base TCP specification in RFC 793 provided only a simple
   cumulative acknowledgment mechanism.  However, a selective
   acknowledgment (SACK) mechanism provides performance improvement in
   the presence of multiple packet losses from the same flight, more
   than outweighing the modest increase in complexity.  A TCP should be
   expected to implement SACK, however SACK is a negotiated option and
   is only used if support is advertised by both sides of a connection.

   RFC 2018 S: "TCP Selective Acknowledgement Options" (October 1996)

      This document [RFC2018] defines the basic selective
      acknowledgement (SACK) mechanism for TCP.

   RFC 2883 S: "An Extension to the Selective Acknowledgement (SACK)
   Option for TCP" (July 2000)

      This document [RFC2883] extends RFC 2018 to cover the case of
      acknowledging duplicate segments.

   RFC 3517 S: "A Conservative Selective Acknowledgement (SACK)-based
   Loss Recovery Algorithm for TCP" (April 2003)

      This document [RFC3517] describes a relatively sophisticated
      algorithm that a TCP sender can use for loss recovery when SACK
      reports more than one segment lost from a single flight of data.
      While support for the exchange of SACK information is widely
      implemented, not all implementations use an algorithm as
      sophisticated as that described in RFC 3517.
"""

Then, in Section 4 - "Experimental Extensions", there are several
relevent entries, all of which represent tweaks to the congestion
control/loss recovery functions (or function):
"""
   RFC 2140 I: "TCP Control Block Interdependence" (April 1997)

      This document [RFC2140] suggests how TCP connections between the
      same endpoints might share information, such as their congestion
      control state.  To some degree, this is done in practice by a few
      operating systems; for example, Linux currently has a destination
      cache.  Although this RFC is technically informational, the
      concepts it describes are in experimental use, so we include it in
      this section.

      A related proposal, the Congestion Manager, is specified in RFC
      3124 [RFC3124].  The idea behind the Congestion Manager, moving
      congestion control outside of individual TCP connections,
      represents a modification to the core of TCP, which supports
      sharing information among TCP connections as well.  Although a
      Proposed Standard, some pieces of the Congestion Manager support
      architecture have not been specified yet, and it has not achieved
      use or implementation beyond experimental stacks, so it is not
      listed among the standard TCP enhancements in this roadmap.

   RFC 2861 E: "TCP Congestion Window Validation" (June 2000)

      This document [RFC2861] suggests reducing the congestion window
      over time when no packets are flowing.  This behavior is more
      aggressive than that specified in RFC 2581, which says that a TCP
      sender SHOULD set its congestion window to the initial window
      after an idle period of an RTO or greater.

   RFC 3465 E: "TCP Congestion Control with Appropriate Byte Counting
   (ABC)" (February 2003)

      This document [RFC3465] suggests that congestion control use the
      number of bytes acknowledged rather than the number of
      acknowledgements received.  This has been implemented in Linux.
      The ABC mechanism behaves differently than the standard method
      when there is not a one-to-one relationship between data segments
      and acknowledgements.  ABC still operates within the accepted
      guidelines, but is more robust to delayed ACKs and ACK-division
      [SCWA99][RFC3449].

   RFC 3522 E: "The Eifel Detection Algorithm for TCP" (April 2003)

      This document [RFC3522] suggests using timestamps to detect
      spurious timeouts.

   RFC 3540 E: "Robust Explicit Congestion Notification (ECN) signaling
   with Nonces" (June 2003)

      This document [RFC3540] suggests a modified ECN to address
      security concerns, and updates RFC 3168.

   RFC 3649 E: "HighSpeed TCP for Large Congestion Windows" (December
   2003)

      This document [RFC3649] suggests a modification to TCP's steady-
      state behavior to efficiently use very large windows.

   RFC 3708 E: "Using TCP Duplicate Selective Acknowledgement (DSACKs)
   and Stream Control Transmission Protocol (SCTP) Duplicate
   Transmission Sequence Numbers (TSNs) to Detect Spurious
   Retransmissions" (February 2004)

      Abstract: "TCP and Stream Control Transmission Protocol (SCTP)
      provide notification of duplicate segment receipt through
      Duplicate Selective Acknowledgement (DSACKs) and Duplicate
      Transmission Sequence Number (TSN) notification, respectively.
      This document presents conservative methods of using this
      information to identify unnecessary retransmissions for various
      applications."  [RFC3708]

   RFC 3742 E: "Limited Slow-Start for TCP with Large Congestion
   Windows" (March 2004)

      This document [RFC3742] describes a more conservative slow-start
      behavior to prevent massive packet losses when a connection uses a
      very large window.

   RFC 4015 S: "The Eifel Response Algorithm for TCP" (February 2005)

      This document [RFC4015] describes the response portion of the
      Eifel algorithm, which can be used in conjunction with one of
      several methods of detecting when loss recovery has been
      spuriously entered, such as the Eifel detection algorithm in RFC
      3522, the algorithm in RFC 3708, or F-RTO in RFC 4138.

      Abstract: "Based on an appropriate detection algorithm, the Eifel
      response algorithm provides a way for a TCP sender to respond to a
      detected spurious timeout.  It adapts the retransmission timer to
      avoid further spurious timeouts, and can avoid - depending on the
      detection algorithm - the often unnecessary go-back-N retransmits
      that would otherwise be sent.  In addition, the Eifel response
      algorithm restores the congestion control state in such a way that
      packet bursts are avoided."

      RFC 4015 is itself a Proposed Standard.  The consensus of the TCPM
      working group was to place it in this section of the roadmap
      document due to three factors.

      1.  RFC 4015 operates on the output of a detection algorithm, for
          which there is currently no available mechanism on the
          standards track.

      2.  The working group was not aware of any wide deployment and use
          of RFC 4015.

      3.  The concensus of the working group, after a discussion of the
          known Intellectual Property Rights claims on the techniques
          described in RFC 4015, identified this section of the roadmap
          as an appropriate location.

   RFC 4138 E: "Forward RTO-Recovery (F-RTO): An Algorithm for Detecting
   Spurious Retransmission Timeouts with TCP and the Stream Control
   Transmission Protocol" (August 2005)

      The F-RTO detection algorithm [RFC4138] provides another option
      for inferring spurious retransmission timeouts.  Unlike some
      similar detection methods, F-RTO does not rely on the use of any
      TCP options.
"""

-- 
Wesley M. Eddy
Verizon Federal Network Systems
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20060322/8db95495/attachment-0001.bin
>From [email-masked]  Thu Mar 23 13:15:44 2006
From: [email-masked] (Aaron Falk)
Date: Thu Mar 23 13:20:00 2006
Subject: [Iccrg] iccrg status at IETF tsvwg meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

On Mar 22, 2006, at 2:15 PM, Aaron Falk wrote:

> On Mar 22, 2006, at 9:45 AM, Aaron Falk wrote:
>
>> I presented the status slides you provided me at the tsvwg meeting
>
> Someone observed privately that, contrary to the status slide,  
> there wasn't yet agreement on a definition of consensus.

whoops, I meant 'congestion' not 'consensus'.

--aaron

From: [email-masked] (Aaron Falk)
Date: Wed Mar 22 20:22:24 2006
Subject: [Iccrg] iccrg status at IETF tsvwg meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Mar 22, 2006, at 9:45 AM, Aaron Falk wrote:

> I presented the status slides you provided me at the tsvwg meeting

Someone observed privately that, contrary to the status slide, there  
wasn't yet agreement on a definition of consensus.  I saw several  
proposals and discussion pass by on the list but haven't been able to  
track it closely.  So, I'd like to ask where the definition on  
congestion is written and is there agreement on it within the RG?

--aaron

From: [email-masked] (Michael Welzl)
Date: Wed Mar 22 19:14:08 2006
Subject: AW: [Iccrg] iccrg status at IETF tsvwg meeting
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

> IMHO, Sending to the list may be a good first approach, but we should 
> also make sure someone takes the text and converts it into something we 
> can all build on...

sure. i'd be happy to contribute to this document in any
possible way, but don't want to obtrude myself on the group.

IMO this overview of standardization would best be modelled
after the TCP roadmap document.

cheers,
michael

From: [email-masked] (Gorry Fairhurst)
Date: Wed Mar 22 18:46:24 2006
Subject: [Iccrg] iccrg status at IETF tsvwg meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

IMHO, Sending to the list may be a good first approach, but we should 
also make sure someone takes the text and converts it into something we 
can all build on...

Gorry

Michael Welzl wrote:

>Hi,
>
>Good idea!
>
>For TCP beyond VJ algorithms, you could simply point to the
>Roadmap document of TCPM.
>
>For the other things, I'd be happy to help:
>
>Since I had to find an order of importance, and figured
>that standardized mechanisms are the most important ones
>to know about, I tried hard to cover all of this in my
>book on congestion control - see
>http://www.welzl.at/congestion/
>
>(I finished it early March 2005, so anything after
>that isn't included - but things like Quick-Start are
>mentioned even though they are (were) only Internet-drafts).
>
>I could, for instance, go through my references list
>and pick out all the RFC and draft citations, and
>send it to someone (the list? Keshav? Aaron? who?).
>
>Just a suggestion...
>
>Cheers,
>Michael
>
>
>On Wed, 2006-03-22 at 16:45, Aaron Falk wrote:
>  
>
>>(cc'ing the rg list)
>>
>>Keshav-
>>
>>I presented the status slides you provided me at the tsvwg meeting  
>>[1] and received a comment which I thought was worth forwarding to  
>>you and the list.  Sally Floyd pointed out in the meeting that there  
>>is a lot of existing IETF congestion control technology other than  
>>the VJ algorithms (e.g., ECN, TFRC, RED).  What she didn't say, but  
>>I'd like to suggest, would be to identify the state of the world in  
>>standardized congestion control, possibly by simply collecting a list  
>>of appropriate citations.
>>
>>--aaron
>>
>>[1] http://www3.ietf.org/proceedings/06mar/slides/tsvwg-12.ppt
>>
>>_______________________________________________
>>Iccrg mailing list
>>[email-masked]
>>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>>    
>>
>
>
>_______________________________________________
>Iccrg mailing list
>[email-masked]
>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>
>  
>

From: [email-masked] (Michael Welzl)
Date: Wed Mar 22 16:21:20 2006
Subject: [Iccrg] iccrg status at IETF tsvwg meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

Good idea!

For TCP beyond VJ algorithms, you could simply point to the
Roadmap document of TCPM.

For the other things, I'd be happy to help:

Since I had to find an order of importance, and figured
that standardized mechanisms are the most important ones
to know about, I tried hard to cover all of this in my
book on congestion control - see
http://www.welzl.at/congestion/

(I finished it early March 2005, so anything after
that isn't included - but things like Quick-Start are
mentioned even though they are (were) only Internet-drafts).

I could, for instance, go through my references list
and pick out all the RFC and draft citations, and
send it to someone (the list? Keshav? Aaron? who?).

Just a suggestion...

Cheers,
Michael

On Wed, 2006-03-22 at 16:45, Aaron Falk wrote:
> (cc'ing the rg list)
> 
> Keshav-
> 
> I presented the status slides you provided me at the tsvwg meeting  
> [1] and received a comment which I thought was worth forwarding to  
> you and the list.  Sally Floyd pointed out in the meeting that there  
> is a lot of existing IETF congestion control technology other than  
> the VJ algorithms (e.g., ECN, TFRC, RED).  What she didn't say, but  
> I'd like to suggest, would be to identify the state of the world in  
> standardized congestion control, possibly by simply collecting a list  
> of appropriate citations.
> 
> --aaron
> 
> [1] http://www3.ietf.org/proceedings/06mar/slides/tsvwg-12.ppt
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Aaron Falk)
Date: Wed Mar 22 15:53:36 2006
Subject: [Iccrg] iccrg status at IETF tsvwg meeting
Message-ID: <[email-masked]>

(cc'ing the rg list)

Keshav-

I presented the status slides you provided me at the tsvwg meeting  
[1] and received a comment which I thought was worth forwarding to  
you and the list.  Sally Floyd pointed out in the meeting that there  
is a lot of existing IETF congestion control technology other than  
the VJ algorithms (e.g., ECN, TFRC, RED).  What she didn't say, but  
I'd like to suggest, would be to identify the state of the world in  
standardized congestion control, possibly by simply collecting a list  
of appropriate citations.

--aaron

[1] http://www3.ietf.org/proceedings/06mar/slides/tsvwg-12.ppt

From: [email-masked] (Ferenc Kubinszky)
Date: Mon Mar 20 13:56:16 2006
Subject: [Iccrg] Timeline and further work
Message-ID: <[email-masked]>

Hi,

The list is quite silent nowdays...
What do you think, can we agree on the output of the last thread 
([Iccrg] Congestion control definition and requirements of a new 
protocol), or at least on section B of it?
The timeline that Keshav gave a bit strict, but for the challenge 
document we have enough topics. I think it's not fair to let Keshav to 
work alone, so if there any problems to discuss, we should do it together.

BR,
Ferenc

From: [email-masked] (louise.burness)
Date: Wed Mar  1 12:11:44 2006
Subject: [Fwd: Re: [Iccrg] Congestion control definition and requirements  of anew protocol]
Message-ID: <[email-masked]>

In-line again, with pruning

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Ferenc Kubinszky
> Sent: 01 March 2006 11:48
> To: S. Keshav; iccrg
> Cc: Gabor Nemeth
> Subject: [Fwd: Re: [Iccrg] Congestion control definition and 
> requirements of anew protocol]
> 
> 
> Hi,
> 
> Please find my comments inline.
> 
> S. Keshav wrote:
> > Folks, 
> >     Its been quiet on this list for a while. Can I take it as 
> > consensus on the following:
> > 
> > A. Definition of Congestion:
> > 
> > Network congestion is a state of degraded performance from the 
> > perspective of a particular user. A network is said to be congested 
> > from the perspective of a user if that user's utility has decreased 
> > due to an increase in network load.
> 
> What does it mean "user's utility has decreased"? Is it an 
> absolute or relative measure? It might be important to 
> distinguish if the source of 
> the increase is the user itself.
> 
> By this definition the network is congested if a user uses 
> the whole capacity of a given link, and an other user will 
> start a flow. Is it really a congestion? This case the 
> network should be congested every time...
> 

I still like the idea of defining congestion caused by a packet at a
single resource as the probability that an event {another packet
lost/marked/delayed beyond specification} if the packet is added to the
load
> 
> 
> > B. Problems with TCP congestion control:
> > 
> > 1. In a high bandwidth-delay product environment, high 
> throughputs can 
> > only be achieved if the packet loss rate is unrealistically low.
> > 
> I agree with this. However new TCPs, like highspeed, 
> scalable, BIC do ~10x better than e.g. reno. But this is a 
> strict constraint for high speed networks.
> 
> > 2. TCP has low throughput under lossy environments because it uses 
> > loss as an indication of congestion.
> 
> Sure. In some networks loss isn't the best congestin 
> detection source. But TCP should somehow know about the 
> congested state of the network (whatever it is). There are 
> other possible measures, like RTT changes, packet inter 
> arrival times etc.

These implicit schemes seem to prove very difficult to implement in
practise - for example all the measures you suggest are affected by the
type of ARQ scheme that the particular wireless link utilises. Explicit
notification is required

 A new congestion control mechanism should 
> combine these wisely. But the problem still remain, namely 
> that the source of these measures is not strictly the 
> congestion. Consider that the packet loss on a link or 
> network mostly convertible to
>    delay (or delay variation, if you wish), and vica versa.
> 
> > > > 
> > 
> > 
> > _______________________________________________
> > Iccrg mailing list
> > [email-masked] http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> 
> 
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked] http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> 

From: [email-masked] (Ferenc Kubinszky)
Date: Wed Mar  1 11:54:40 2006
Subject: [Fwd: Re: [Iccrg] Congestion control definition and requirements of a new protocol]
Message-ID: <[email-masked]>

Hi,

Please find my comments inline.

S. Keshav wrote:
> Folks, 
>     Its been quiet on this list for a while. Can I take it as consensus on
> the following:
> 
> A. Definition of Congestion:
> 
> Network congestion is a state of degraded performance from the perspective
> of a particular user. A network is said to be congested from the perspective
> of a user if that user's utility has decreased due to an increase in network
> load. 

What does it mean "user's utility has decreased"? Is it an absolute or
relative measure? It might be important to distinguish if the source of 
the increase is the user itself.

By this definition the network is congested if a user uses the whole
capacity of a given link, and an other user will start a flow. Is it
really a congestion? This case the network should be congested every time...

> B. Problems with TCP congestion control:
> 
> 1. In a high bandwidth-delay product environment, high throughputs can only
> be achieved if the packet loss rate is unrealistically low.
> 
I agree with this. However new TCPs, like highspeed, scalable, BIC do
~10x better than e.g. reno. But this is a strict constraint for high
speed networks.

> 2. TCP has low throughput under lossy environments because it uses loss as
> an indication of congestion.

Sure. In some networks loss isn't the best congestin detection source.
But TCP should somehow know about the congested state of the network
(whatever it is). There are other possible measures, like RTT changes,
packet inter arrival times etc.
A new congestion control mechanism should combine these wisely. But the
problem still remain, namely that the source of these measures is not
strictly the congestion.
Consider that the packet loss on a link or network mostly convertible to
   delay (or delay variation, if you wish), and vica versa.

> 3. Due to additive increase, it takes a long time for a flow to ramp up to
> transient increases in available capacity which results in unnecessarily
> long flow-completion times.
> 
Its true and it might be important in future networks.
Maybe 'transient' is not the proper word for this, because the change in
capacity may be sudden, but it may stay on the new level for a long time.

I would split this point into 2 sub section like this:

3. Sudden changes in network/link characteristics

Sudden change in network characteristics might be caused by changes in
the network path, changes in the number of users on a given link.

a) Capacity changes
  ** Your definition here **
  ++ I think that sudden capacity degradation might be examined too.
This might cause buffer overruns and bursty losses.

b) Base RTT changes
  As link characteristics change there might be changes in RTT values.
This might be negligible, but should not cause any problem to future
protocols.

> 4. Even when the flow is capable of completing within a round-trip time,
> slow-start makes flows last multiple round-trip times just to find their
> fair share rate. Many flows complete before they exit slow-start phase.   
> 
> 5. TCP fills up all available buffers at the bottleneck links, which results
> in long latency. 
> 
> 6. TCP  shares bandwidth inversely proportional to flow RTTs
> 
> 7. TCP builds a standing queue at the point of congestion, which increases
> the delay. 

8. Impact of jitter (this section should come after loss)
Today's TCPs perform poorly in networks with high jitter.

> -------
> 
> If we agree on this, (and if you do not, this is the time to speak up) I
> would like to propose that we discuss the requirements of a new congestion
> control protocol, both theoretically and practically.
> 
> To start off this debate, I would like to state the following top level
> requirements. 
> 
> First, given the definition of congestion, I argue that the proposed
> protocol should allow two things: decoupling and observability.
> 
>     0 Decoupling means that the traffic from one user should not affect (or
> minimally affect) other users.
>     0 Observability means that users should be able to observe the network
> state in some fashion, so that they can control their input so as to not
> cause overload and a consequent decrease in utility.
> 
> Second, in addition to these, the new mechanism should also not suffer from
> the seven problems with TCP.
> 
> Comments?
> 
> thanks
> 
> keshav
> 
> 
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg