[e2e] Are we doing sliding window in the Internet?

[Jitu Padhye]

This is a starting point:

http://www.ietf.org/rfc/rfc5033.txt



-----Original Message-----
From: end2end-interest-bounces at postel.org [mailto:end2end-interest-bounces at postel.org] On Behalf Of Debo Dutta (dedutta)
Sent: Sunday, January 06, 2008 1:42 AM
To: Lars Eggert; ext Injong Rhee
Cc: Randy Bush; David P. Reed; end2end-interest at postel.org; Joe Touch
Subject: Re: [e2e] Are we doing sliding window in the Internet?

Hi Lars

I had some simple questions regarding the process from papers --> IETF:
What are some of the metrics that could be used during discussions to
decide whether a protocol crosses the bar? Does someone need to validate
the protocol in very large networks with realistic background traffic
patterns? Are there some standard topologies and background traffic
patterns under which the protocol needs to perform well? If so, this
would be very useful as reference scenarios for everyone.

Regards
Debo


-----Original Message-----
From: end2end-interest-bounces at postel.org
[mailto:end2end-interest-bounces at postel.org] On Behalf Of Lars Eggert
Sent: Sunday, January 06, 2008 1:06 AM
To: ext Injong Rhee
Cc: Randy Bush; David P. Reed; end2end-interest at postel.org; Joe Touch
Subject: Re: [e2e] Are we doing sliding window in the Internet?

Hi,

On 2008-1-5, at 13:16, ext Injong Rhee wrote:
> I am not sure either whether it is the job of  IETF to prove it is
> safe and harmless-- how do they know?

when the IETF publishes RFCs, it needs to classify them into
Experimental or Standards tracks. (There are also BCPs and Informational
RFCs, but those aren't quite appropriate here.) So it is the IETF that
needs to decide whether something is "safe for experimentation" and
under what conditions (Experimental RFC), or whether something is
"recommended for production use" (Standards Track
RFC.)

Because congestion control is essential for the stable operation of the
Internet, the transport area has a pretty high bar for declaring
something "recommended for production use." I agree with you that what
is needed to pass that bar isn't well-defined. I don't think it can be
- different proposals will require different arguments based on
different kinds of data in order to come to consensus in a WG on whether
it is safe for experimentation or not, or can be recommended for
production use or not.

There are currently three TCP variants (CUBIC, C-TCP and HTCP) that have
made the jump from research paper to preliminary specification as
Internet Drafts. As you know, the transport area has asked the IRTF's
congestion control research group to help evaluate which of these three
should be published as Experimental RFCs. (See
http://www.ietf.org/IESG/content/ions/ion-tsv-alt-cc.txt)
  I fully expect several of the three or even all of them to be
published as Experimental RFCs.

After there is some experience from that experimental deployment, we'll
think about recommending one of the variants (or maybe a spinoff or
merge of one or more variants) for production use.

>  When those "standard" algorithms are IETF standardized, had they more

> evaluation than CUBIC/BIC? At best, they had ns-2 simulation.
> Back then there is no definition of realistic traffic patterns.

Well, the whole Internet was a small experimental testbed back then, and
one with broken congestion control. That's very different from the
current situation, where we have a commercial internetwork that has
functioning congestion control (in the sense of preventing congestion
collapse and establishing some sort of fairness) and there is a desire
to deploy modifications that incrementally improve that congestion
control under some conditions. Today, we need to be careful not to break
something that works. Back then, people were fixing something that
didn't work.

Finally, I'm personally very happy to see new research work coming to
the transport area! Although the IETF standardization process can be
tedious and takes time, the in-depth review and implementation efforts
that often go along with it do improve the quality of the result.

Lars