Subject: [Tsvwg] HEADS UP: presenters - email slides

From: Lars Eggert <[email-masked]>
Date: Mon, 6 Nov 2006 08:46:39 -0800

Hi, presenters,

if you haven't done so already, please email your slides to the  
chairs well before the meeting tomorrow, so we can upload them to the  
meeting material manager.

Thanks,
Lars
-- 
Lars Eggert                                     NEC Network Laboratories

---

From: Sally Floyd <[email-masked]>
Date: Mon, 6 Nov 2006 19:21:19 -0800

Slides for Specifying New Congestion Control Algorithms:

http://www.icir.org/floyd/talks/cc-Nov06.ppt
http://www.icir.org/floyd/talks/cc-Nov06.pdf

- Sally
http://www.icir.org/floyd/

---

From: Joe Touch <[email-masked]>
Date: Tue, 07 Nov 2006 08:55:32 -0800

Has an agenda been posted?

---

From: Lars Eggert <[email-masked]>
Date: Tue, 7 Nov 2006 09:01:27 -0800

> Has an agenda been posted?

Yes: http://www3.ietf.org/proceedings/06nov/agenda/tsvwg.txt

Lars

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 07 Nov 2006 18:12:57 +0000

Lars,

Slides for:

 >Bob - Re-ECN: Adding Accountability for Causing Congestion to TCP/IP
 >  draft-briscoe-tsvwg-re-ecn-tcp-03                          1620-1630
 >
 >                                                             (10min)

<http://www.cs.ucl.ac.uk/staff/B.Briscoe/presents/0611ietf/0611briscoe-tsvwg-re-ecn.pdf>
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/presents/0611ietf/0611briscoe-tsvwg-re-ecn.ppt>

(Note: title in agenda is another draft I haven't updated since last 
presented).

Bob

>meeting material manager.

____________________________________________________________________________
Notice: This contribution is the personal view of the author and does not 
necessarily reflect the technical nor commercial direction of BT plc.
____________________________________________________________________________
Bob Briscoe,                           Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196

---

From: Lars Eggert <[email-masked]>
Date: Tue, 7 Nov 2006 13:30:58 -0800

On Nov 6, 2006, at 8:46, Lars Eggert wrote:
> chairs well before the meeting tomorrow, so we can upload them to  
> the meeting material manager.

We're still missing six presentations - please email them ASAP!

(Here is what we have received so far: https://datatracker.ietf.org/ 
public/meeting_materials.cgi?meeting_num=67 and then scroll down to  
TSVWG.)

Lars

---

From: "Injong Rhee" <[email-masked]>
Date: Fri, 10 Nov 2006 14:47:50 -0500

The slide tries to roughly define "fairness to TCP" as a 
criterion for new CC protocols. As an example, it uses
HSTCP being "safe to deploy". Also it says 
"In environments 
where standard congestion control
is able to make reasonable use of the available
bandwidth the proposed change should not
significantly change this state."

Does this mean that any
new CC has similar or better TCP fairness as HSTCP, 
then the protocol is TCP fair? The fairness of HSTCP is hard to 
define and in fact, it is not behaving strictly the 
same way as TCP even in the regime where the authors
say "the standard TCP makes reasonable use of the available
bandwidth." Moreover this regime is hard to define. 

Furthermore, most TCP fairness tests I have seen just
include TCP flows without any receiver window limit.
The typical internal flows, in my understanding, use
64KB as the limit. So if the fairness is an issue because
of use of bandwidth in the Internet, then it should be 
tested with this constraint.

---

From: John Heffner <[email-masked]>
Date: Sat, 11 Nov 2006 18:21:21 -0500

Injong Rhee wrote:
> of use of bandwidth in the Internet, then it should be tested with this 
> constraint.

It's highly likely this fact will change in the near future.  The linux 
kernel by default is now shipping with a max of 4MB, and Vista is 
rumored to have a similar behavior.

   -John

---

From: Sally Floyd <[email-masked]>
Date: Mon, 13 Nov 2006 18:56:59 -0800

> The slide tries to roughly define "fairness to TCP" as a criterion for 
> new CC protocols. As an example, it uses
> HSTCP being "safe to deploy". Also it says "In environments where 
> standard congestion control
> new CC has similar or better TCP fairness as HSTCP, then the protocol 
> is TCP fair?

The document doesn't attempt to give a definition for what is TCP fair, 
or
to give detailed requirements.   The draft itself, 
draft-floyd-cc-alt-00.txt,
says the following:

    "This document provides guidelines for the IETF to use when
    evaluating suggested congestion control algorithms",

and:

    "This document does not give hard-and-fast rules for what makes for
     an appropriate congestion control scheme.  Rather, the document
     provides a set of criteria that should be considered and weighed by
     the IETF in the context of each proposal.  The high-order criteria
     for any new proposal is that a serious scientific study of the pros
     and cons of the proposal needs to have been done such that the IETF
     has a well rounded set of information to consider."

However, RFC 3649 (HSTCP) has been Experimental since 2003, with
a paragraph in the abstract saying:

    "The proposals in this document are experimental.  While they may be
    deployed in the current Internet, they do not represent a consensus
    that this is the best method for high-speed congestion control."

So I take this as an explicit endorsement from the IETF that the 
variant of
fairness in HSTCP, which is more aggressive than Standard TCP in
environments where TCP is judged not to be able to make good use
of the available bandwidth, is perfectly acceptable (though not 
necessarily
"the best method for high-speed congestion control".)

>  The fairness of HSTCP is hard to define and in fact, it is not 
> behaving strictly the same way as TCP even in the regime where the 
> authors

To first order, the fairness of HSTCP can be defined by the response 
function.
And of course, this is complicated by convergence times and other 
dynamics that
aren't captured in the response function.  And yes, nothing in the area 
of
"fairness" lends itself to strict or precise definitions.  (E.g., 
Section 3.3 on
"The Amorphous Problem of Fairness" from RFC 3714 on "IAB Concerns
Regarding Congestion Control for Voice Traffic in the Internet".

> of use of bandwidth in the Internet, then it should be tested with 
> this constraint.

I think it is useful to test fairness both for receiver-limited
and non-receiver-limited flows.  (However, HSTCP is only
relevant for non-receiver-limited flows - otherwise, HSTCP defaults to
Standard TCP.  That is, for a HSTCP TCP flow whose congestion
window never exceeds 38 MSS, the behavior is *exactly* the same
as that of Standard TCP, by definition.)

- Sally

---

From: "Injong Rhee" <[email-masked]>
Date: Tue, 14 Nov 2006 15:23:23 -0500

This brings up a good issue regarding tcp fairness. Is this fairness with 
respect to fairness with existing TCP or the future TCPs? The future 
versions are going to do whatever they want -- so is there need to be fair 
to them? Or is this fairness with respect to the IETF standard? Then why do 
we care about fairness to TCP then since the current TCP does nor work well 
in some distinct situations of the Internet and we are trying to change 
that, and furthermore, the current Internet is used by some standard TCP 
flows with the 64KB constraint. I am confused.

----- Original Message ----- 
From: "John Heffner" <[email-masked]>
To: "Injong Rhee" <[email-masked]>
Cc: "tsvwg" <[email-masked]>
Sent: Saturday, November 11, 2006 6:21 PM
Subject: Re: [Tsvwg] Comments on Sally and Mark's slides

> kernel by default is now shipping with a max of 4MB, and Vista is rumored 
> to have a similar behavior.
>
>   -John
>

---

From: Mark Allman <[email-masked]>
Date: Thu, 16 Nov 2006 12:32:33 -0500

> Or is this fairness with respect to the IETF standard? Then why do we
> care about fairness to TCP then since the current TCP does nor work
> well in some distinct situations of the Internet and we are trying to
> change that, and furthermore, the current Internet is used by some
> standard TCP flows with the 64KB constraint. I am confused.

Fairness is really quite fuzzy, right?  Two bits:

  + In the situations you mention above when IETF TCP cannot make use of
    the available capacity for whatever reason then new proposals are
    not constrained to the same rate.  Obviously, that would mean new
    proposals would be useless.  Say IETF TCP and NEW TCP are sharing
    some bottleneck and so nominally it'd be nice if each got X/2 of
    capacity.  But, say IETF TCP can only get X/4 (with or without the
    competing flow) for whatever reason.  The NEW TCP flow could
    certainly still use X/2 of capacity.  And, further, it'd be fine if
    the NEW TCP flow slurped up spare capacity and so used 3X/4---why
    let the spare capacity go to waste if someone can make good use of
    it?  The situation we are trying to avoid here is the case when NEW
    TCP comes along and takes 95X/100, thus relegating IETF TCP to a
    much smaller fraction than it could otherwise claim (X/20 as opposed
    to X/4).

  + Now, take the case when two IETF TCPs are humming along each at
    X/2.  In this case, there is no problem to be solved by NEW TCP.
    So, if one of the flows is NEW TCP then it should likewise get X/2
    and not have a big impact on IETF TCP, which is working just fine.
    This is not the regime where we need a new algorithm.

The document doesn't mean to put hard and fast rules in place.  In other
words, if NEW TCP in the second example above were to get 55X/100 and
cause IETF TCP to decrease to 45X/100 then maybe that is just fine.
This is not all black and white.  We simply wanted to sketch general
criteria that people could keep in mind as they are experimenting with
these new algorithms and that the IETF could use as a guideline to
reasoning about the new algorithms in the standards context.  hard
judgments on the reasonableness of each algorithm will come as those
algorithms are specified.

I hope that helps.

allman

---

From: Erblichs <[email-masked]>
Date: Thu, 16 Nov 2006 16:59:28 -0800

Mark Allman,,

	First, what is equality? bits per second? packets per second?
	same number of bytes increase per round trip for additive increase?
	Is it fair if a network limited flow is keep at the same bandwidth 
	rate as a application limited flow? Should the app flow get more
	bandwith on a temporary basis than the network limited flow??

	2nd bit.. 
	Humming along at X/2. No, both are doing a additive
	increase. They don't reach stasis, equality and stop at a
	specific bandwidth. They are always asking for more as long
	as they are network limited. Right??? If so, the much faster
	rtt flow would be increasing at a faster rate. So if they
	both started at 0%, couldn't one flow use even 90% while
	the other reached 10%. Is this trying to reach equality???
	This is using the same TCP implementation...

	So, first, why don't they ever in even theory attempt to 
	achieve stasis?? Why can't if two flows that have infinite
	duration achieve the same level of equality if they have
	diff rtts????

	What is wrong with a new flow from getting more bandwidth
	wrt a older flow? In UNIX process timeshare scheduling a new process
	will get a high percentage of available resource in case he can run and
	just finish his work.

	With respect to flows, don't we want to allow the new flow to
	get enough bandwidth in case he is a application limited bandwidth
	flow or that he is equivalent to the interactive type process with
	a bursty nature??  We assume that the older flow might be a long
	duration flow, so we allocate some of his bandwidth on a temporary
	nature.

	However, TCP doesn't recognize priorities of flows or their
	percentage of usage of a medium's capacity. So isn't the best we
	can do is allow during time 1, flow 2 to use 55% or 60% of the
	capacity, while flow 1 uses 40 to 45%, and flop at each time
	period????

	I just don't see how any process could enforce equality. And if
	you tried, would the long term flow be penalized for using excess
	capacity while other short duration flows were really application
	limited?

	In summary, I don't think the common parts of TCP seek to strive
	for equality amoung multiple flows. If you are seeking this, I
	believe that some well known sections of TCP need re-thinking.

	Mitchell Erblich
	----------------------

Mark Allman wrote:
>   ------------------------------------------------------------------------
>    Part 1.2Type: application/pgp-signature

---

From: Mark Allman <[email-masked]>
Date: Thu, 16 Nov 2006 22:53:43 -0500

Mitchell-

I think we have a large impedance mismatch here.  

Sally and I are trying to write down a set of high level guidelines
here.  And, I wrote a couple of *illustrative* examples in my last
email.  Questions about whether we think about bps or pps or how fast
additive increase is or whether some flow is app limited or not are just
not at the right level for our document.  Those questions will be fine
to consider and weigh when there is a concrete proposal on the table and
the IETF is considering what to do with it.  The devil is certainly in
the details and the IETF community will have to work through the details
of various proposals.  As has been noted previously in this thread, a
bunch of this stuff is not black and white.  I cannot give you a
concrete formula to see if some TCP "passes".  The consideration of the
details will involve solid scientific experiments, as well as sound
engineering judgment.  We are simply highlighting areas that should be
thought about, considered and studied as new CC schemes are developed.

I don't want to belabor the specific point we're trying to make here,
but again, all we are really saying is that some new fangled CC
algorithm should not starve the old fangled algorithm.  I don't think
that is unreasonable in any way as a general principle.  If folks think
that it is a lousy general notion then you should yell and we'll see
what sort of consensus develops.

allman

---

From: Erblichs <[email-masked]>
Date: Mon, 20 Nov 2006 16:49:14 -0800

Mark Allman,

	Thats not fair....

	What I read in the slides is one evaluation criteria
	for possible review of the IETF for NEW TCP proposals.

	What I am trying to ask in my long winded way is 
	whether OUR current TCP RFCs allow unequalities to 
	exist wrt multiple flows on ALL TCP implementations?
	
	It is my contention that we have inequality in some
	of even the simplest parts of TCP. That is assuming
	that we want in the simplest sense to support some type 
	equal sharing between just two flows.

	Actually that isn't strong enough. Some of the most
	fundamentatal parts of TCP FORCE inequality and they
	always force flows, sometime into the future, congestion,
	as-long-as they are network limited. CC then destroys
	our network utiilization.

	Mitchell Erblich
	--------------------

---

From: Mark Allman <[email-masked]>
Date: Mon, 20 Nov 2006 20:27:13 -0500

> 	for possible review of the IETF for NEW TCP proposals.

Yes.  (I can't recall the slides precisely.  Sally passed them by me
before the meeting.  I would encourage you to read the i-d.)

> 	exist wrt multiple flows on ALL TCP implementations?

Sure.  I think that is well established.

I don't think that negates what I said.  If you think some specific text
in the i-d needs changed, it would be nice to highlight that for us
(and, suggested text is always welcome, too).

Thanks,
allman