Subject: [Iccrg] Preliminary agenda for the next meeting
From: [email-masked] (Michael Welzl)
Date: Fri Feb 29 16:25:42 2008

hi,

it's there - you must've overlooked it?!  15:30
http://www3.tools.ietf.org/group/irtf/trac/wiki/Agenda08

cheers
michael

----- Original Message ----- 
From: "Dirceu Cavendish" <[email-masked]>
To: "Michael Welzl" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, February 29, 2008 5:27 PM
Subject: Re: [Iccrg] Preliminary agenda for the next meeting

> Michael,
>
> I do not see my slot in the agenda. Did it get "reclaimed"? I am going to
the UK mainly for this meeting...
>
> Please advise,
>
> Dirceu Cavendish
>
>
> ----- Original Message ----
> From: Bob Briscoe <[email-masked]>
> To: Michael Welzl <[email-masked]>
> Cc: [email-masked]
> Sent: Friday, February 29, 2008 8:02:48 AM
> Subject: Re: [Iccrg] Preliminary agenda for the next meeting
>
> Michael,
>
> I'm not clear whether/how I need to register if I'm only going to
> attend the ICCRG (and the evening dinner) but not PFLDnet (as I have
> to be elsewhere Thu).
>
>
> Bob
>
> At 03:51 01/02/2008, Michael Welzl wrote:
> >Dear all,
> >
> >Here's the first version of the agenda for our next
> >meeting (Manchester, with Pfldnet 2008:
> >http://www.hep.man.ac.uk/PFLDnet2008/  - this is
> >the page to check for all logistics details).
> >
> > >From the input that I got, it is now clear that this
> >meeting will only take a day, and that day will be
> >Wednesday, the 5th of March. The PFLDNet reception
> >will take place on the same day, after our meeting.
> >
> >The ICCRG meeting agenda is below and also at
> >http://www3.tools.ietf.org/group/irtf/trac/wiki/Agenda08
> >
> >09:00 - 09:15 Michael Welzl: Welcome and agenda bashing
> >09:15 - 10:15 Volker Hilt: SIP overload control
> >10:15 - 10:45 Dimitri Papadimitriou: Open research issues in Internet
> >congestion control
> >10:45 - 11:00 Break
> >11:00 - 12:00 Discussion of open issues in Internet congestion control
> >12:00 - 13:00 Lunch
> >13:00 - 13:30 Injong Rhee: CUBIC
> >13:30 - 14:00 Doug Leith: CTCP evaluation results
> >14:00 - 14:30 Lachlan Andrew: Getting more information from ECN bits
> >15:15 - 15:30 Break
> >15:30 - 16:30 Open discussion about future work
> >
> >
> >---
> >
> >Some explanations / comments from my side:
> >
> >(as Lars also pointed out to me, but that's a 100% match
> >with my personal opinion) - the congestion control community
> >should not be stuck with TCP all the time; we really should
> >try to look over the fence and see where else congestion
> >control is needed. This is a part of the role that the
> >"open issues in Internet CC." draft (which Dimitri
> >will present) can take, and Volker Hilt's talk fits in
> >there just perfectly.
> >
> >This is why we have the long slot about discussing open
> >issues. We could use it to take another look at the
> >open issues we already identified previously, and Lars
> >offered to present some open issues in cc. from elsewhere
> >in the IETF, which would also fit in that time slot.
> >
> >CUBIC, in the afternoon, is about the current state of
> >the draft. Injong (or a colleague - he wasn't sure if
> >he'll come himself, but somebody will definitely be there)
> >should present the draft, comments he got, and how he
> >intends to address them.
> >
> >Let me know if you have any comments - and, as you
> >can tell, there would still be some time to squeeze
> >in a short talk or two in the afternoon, if somebody
> >wants to. The open discussion doesn't have to be that
> >long (do we need it at all? I just put it there in
> >case we want to go on discussing things...), and we
> >could end slightly later (although not a lot).
> >
> >
> >--------
> >
> >PARTICIPATION:
> >
> >If your name is not on the agenda, and you would to
> >participate (and your name is not Filipe or Lars  :-)
> >because these are the two that I already know about),
> >drop me a line so I can put you on the list.
> >
> >
> >Cheers,
> >Michael
> >
> >
> >
> >_______________________________________________
> >Iccrg mailing list
> >[email-masked]
> >http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>
____________________________________________________________________________
> Bob Briscoe, <[email-masked]>      Networks Research Centre, BT
Research
> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473
645196
>
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>
>
____________________________________________________________________________
________
> Looking for last minute shopping deals?
> Find them fast with Yahoo! Search.
http://tools.search.yahoo.com/newsearch/category.php?category=shopping

From: [email-masked] (Dirceu Cavendish)
Date: Fri Feb 29 16:23:16 2008
Subject: [Iccrg] Preliminary agenda for the next meeting
Message-ID: <[email-masked]>

Michael,

I do not see my slot in the agenda. Did it get "reclaimed"? I am going to the UK mainly for this meeting...

Please advise,

Dirceu Cavendish

----- Original Message ----
From: Bob Briscoe <[email-masked]>
To: Michael Welzl <[email-masked]>
Cc: [email-masked]
Sent: Friday, February 29, 2008 8:02:48 AM
Subject: Re: [Iccrg] Preliminary agenda for the next meeting

Michael,

I'm not clear whether/how I need to register if I'm only going to 
attend the ICCRG (and the evening dinner) but not PFLDnet (as I have 
to be elsewhere Thu).

Bob

At 03:51 01/02/2008, Michael Welzl wrote:
>Dear all,
>
>Here's the first version of the agenda for our next
>meeting (Manchester, with Pfldnet 2008:
>http://www.hep.man.ac.uk/PFLDnet2008/  - this is
>the page to check for all logistics details).
>
> >From the input that I got, it is now clear that this
>meeting will only take a day, and that day will be
>Wednesday, the 5th of March. The PFLDNet reception
>will take place on the same day, after our meeting.
>
>The ICCRG meeting agenda is below and also at
>http://www3.tools.ietf.org/group/irtf/trac/wiki/Agenda08
>
>09:00 - 09:15 Michael Welzl: Welcome and agenda bashing
>09:15 - 10:15 Volker Hilt: SIP overload control
>10:15 - 10:45 Dimitri Papadimitriou: Open research issues in Internet
>congestion control
>10:45 - 11:00 Break
>11:00 - 12:00 Discussion of open issues in Internet congestion control
>12:00 - 13:00 Lunch
>13:00 - 13:30 Injong Rhee: CUBIC
>13:30 - 14:00 Doug Leith: CTCP evaluation results
>14:00 - 14:30 Lachlan Andrew: Getting more information from ECN bits
>15:15 - 15:30 Break
>15:30 - 16:30 Open discussion about future work
>
>
>---
>
>Some explanations / comments from my side:
>
>(as Lars also pointed out to me, but that's a 100% match
>with my personal opinion) - the congestion control community
>should not be stuck with TCP all the time; we really should
>try to look over the fence and see where else congestion
>control is needed. This is a part of the role that the
>"open issues in Internet CC." draft (which Dimitri
>will present) can take, and Volker Hilt's talk fits in
>there just perfectly.
>
>This is why we have the long slot about discussing open
>issues. We could use it to take another look at the
>open issues we already identified previously, and Lars
>offered to present some open issues in cc. from elsewhere
>in the IETF, which would also fit in that time slot.
>
>CUBIC, in the afternoon, is about the current state of
>the draft. Injong (or a colleague - he wasn't sure if
>he'll come himself, but somebody will definitely be there)
>should present the draft, comments he got, and how he
>intends to address them.
>
>Let me know if you have any comments - and, as you
>can tell, there would still be some time to squeeze
>in a short talk or two in the afternoon, if somebody
>wants to. The open discussion doesn't have to be that
>long (do we need it at all? I just put it there in
>case we want to go on discussing things...), and we
>could end slightly later (although not a lot).
>
>
>--------
>
>PARTICIPATION:
>
>If your name is not on the agenda, and you would to
>participate (and your name is not Filipe or Lars  :-)
>because these are the two that I already know about),
>drop me a line so I can put you on the list.
>
>
>Cheers,
>Michael
>
>
>
>_______________________________________________
>Iccrg mailing list
>[email-masked]
>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196 

_______________________________________________
Iccrg mailing list
[email-masked]
http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20080229/a952b449/attachment.html
>From [email-masked]  Fri Feb 29 16:31:26 2008
From: [email-masked] (Michael Welzl)
Date: Fri Feb 29 16:24:31 2008
Subject: [Iccrg] Preliminary agenda for the next meeting
References: <[email-masked]>
	<[email-masked]>
Message-ID: <005701c87af0$87bf9ac0$0200a8c0@fun>

Hi Bob,

You are herewith registered!  :-)

(since you cc'ed the list, I do the same, and explain, for everyone:
generally, we won't kick people out who didn't register, but if you
could send me a note saying that you'd like to attend that would be
appreciated)

Bob - regarding your previous email, would you like to give
a talk about this stuff in Manchester? It surely would be of interest
to the group

if so, give me a title and suggested length please.

Cheers,
Michael

PS: I'll announce that the agenda is final + provide some
more details about the meeting in an email later today, or
tomorrow...

----- Original Message ----- 
From: "Bob Briscoe" <[email-masked]>
To: "Michael Welzl" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, February 29, 2008 5:02 PM
Subject: Re: [Iccrg] Preliminary agenda for the next meeting

> Michael,
>
> I'm not clear whether/how I need to register if I'm only going to
> attend the ICCRG (and the evening dinner) but not PFLDnet (as I have
> to be elsewhere Thu).
>
>
> Bob
>
> At 03:51 01/02/2008, Michael Welzl wrote:
> >Dear all,
> >
> >Here's the first version of the agenda for our next
> >meeting (Manchester, with Pfldnet 2008:
> >http://www.hep.man.ac.uk/PFLDnet2008/  - this is
> >the page to check for all logistics details).
> >
> > >From the input that I got, it is now clear that this
> >meeting will only take a day, and that day will be
> >Wednesday, the 5th of March. The PFLDNet reception
> >will take place on the same day, after our meeting.
> >
> >The ICCRG meeting agenda is below and also at
> >http://www3.tools.ietf.org/group/irtf/trac/wiki/Agenda08
> >
> >09:00 - 09:15 Michael Welzl: Welcome and agenda bashing
> >09:15 - 10:15 Volker Hilt: SIP overload control
> >10:15 - 10:45 Dimitri Papadimitriou: Open research issues in Internet
> >congestion control
> >10:45 - 11:00 Break
> >11:00 - 12:00 Discussion of open issues in Internet congestion control
> >12:00 - 13:00 Lunch
> >13:00 - 13:30 Injong Rhee: CUBIC
> >13:30 - 14:00 Doug Leith: CTCP evaluation results
> >14:00 - 14:30 Lachlan Andrew: Getting more information from ECN bits
> >15:15 - 15:30 Break
> >15:30 - 16:30 Open discussion about future work
> >
> >
> >---
> >
> >Some explanations / comments from my side:
> >
> >(as Lars also pointed out to me, but that's a 100% match
> >with my personal opinion) - the congestion control community
> >should not be stuck with TCP all the time; we really should
> >try to look over the fence and see where else congestion
> >control is needed. This is a part of the role that the
> >"open issues in Internet CC." draft (which Dimitri
> >will present) can take, and Volker Hilt's talk fits in
> >there just perfectly.
> >
> >This is why we have the long slot about discussing open
> >issues. We could use it to take another look at the
> >open issues we already identified previously, and Lars
> >offered to present some open issues in cc. from elsewhere
> >in the IETF, which would also fit in that time slot.
> >
> >CUBIC, in the afternoon, is about the current state of
> >the draft. Injong (or a colleague - he wasn't sure if
> >he'll come himself, but somebody will definitely be there)
> >should present the draft, comments he got, and how he
> >intends to address them.
> >
> >Let me know if you have any comments - and, as you
> >can tell, there would still be some time to squeeze
> >in a short talk or two in the afternoon, if somebody
> >wants to. The open discussion doesn't have to be that
> >long (do we need it at all? I just put it there in
> >case we want to go on discussing things...), and we
> >could end slightly later (although not a lot).
> >
> >
> >--------
> >
> >PARTICIPATION:
> >
> >If your name is not on the agenda, and you would to
> >participate (and your name is not Filipe or Lars  :-)
> >because these are the two that I already know about),
> >drop me a line so I can put you on the list.
> >
> >
> >Cheers,
> >Michael
> >
> >
> >
> >_______________________________________________
> >Iccrg mailing list
> >[email-masked]
> >http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>
____________________________________________________________________________
> Bob Briscoe, <[email-masked]>      Networks Research Centre, BT
Research
> B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473
645196
>
>

From: [email-masked] (Bob Briscoe)
Date: Fri Feb 29 15:59:50 2008
Subject: [Iccrg] Preliminary agenda for the next meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Michael,

I'm not clear whether/how I need to register if I'm only going to 
attend the ICCRG (and the evening dinner) but not PFLDnet (as I have 
to be elsewhere Thu).

Bob

At 03:51 01/02/2008, Michael Welzl wrote:
>Dear all,
>
>Here's the first version of the agenda for our next
>meeting (Manchester, with Pfldnet 2008:
>http://www.hep.man.ac.uk/PFLDnet2008/  - this is
>the page to check for all logistics details).
>
> >From the input that I got, it is now clear that this
>meeting will only take a day, and that day will be
>Wednesday, the 5th of March. The PFLDNet reception
>will take place on the same day, after our meeting.
>
>The ICCRG meeting agenda is below and also at
>http://www3.tools.ietf.org/group/irtf/trac/wiki/Agenda08
>
>09:00 - 09:15 Michael Welzl: Welcome and agenda bashing
>09:15 - 10:15 Volker Hilt: SIP overload control
>10:15 - 10:45 Dimitri Papadimitriou: Open research issues in Internet
>congestion control
>10:45 - 11:00 Break
>11:00 - 12:00 Discussion of open issues in Internet congestion control
>12:00 - 13:00 Lunch
>13:00 - 13:30 Injong Rhee: CUBIC
>13:30 - 14:00 Doug Leith: CTCP evaluation results
>14:00 - 14:30 Lachlan Andrew: Getting more information from ECN bits
>15:15 - 15:30 Break
>15:30 - 16:30 Open discussion about future work
>
>
>---
>
>Some explanations / comments from my side:
>
>(as Lars also pointed out to me, but that's a 100% match
>with my personal opinion) - the congestion control community
>should not be stuck with TCP all the time; we really should
>try to look over the fence and see where else congestion
>control is needed. This is a part of the role that the
>"open issues in Internet CC." draft (which Dimitri
>will present) can take, and Volker Hilt's talk fits in
>there just perfectly.
>
>This is why we have the long slot about discussing open
>issues. We could use it to take another look at the
>open issues we already identified previously, and Lars
>offered to present some open issues in cc. from elsewhere
>in the IETF, which would also fit in that time slot.
>
>CUBIC, in the afternoon, is about the current state of
>the draft. Injong (or a colleague - he wasn't sure if
>he'll come himself, but somebody will definitely be there)
>should present the draft, comments he got, and how he
>intends to address them.
>
>Let me know if you have any comments - and, as you
>can tell, there would still be some time to squeeze
>in a short talk or two in the afternoon, if somebody
>wants to. The open discussion doesn't have to be that
>long (do we need it at all? I just put it there in
>case we want to go on discussing things...), and we
>could end slightly later (although not a lot).
>
>
>--------
>
>PARTICIPATION:
>
>If your name is not on the agenda, and you would to
>participate (and your name is not Filipe or Lars  :-)
>because these are the two that I already know about),
>drop me a line so I can put you on the list.
>
>
>Cheers,
>Michael
>
>
>
>_______________________________________________
>Iccrg mailing list
>[email-masked]
>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196 

From: [email-masked] (Bob Briscoe)
Date: Fri Feb 29 13:32:48 2008
Subject: [Iccrg] Small packets open issue: draft-briscoe-tsvwg-byte-pkt-mark-02
Message-ID: <[email-masked]>

Folks,

This draft relates closely to the open research issue on small 
packets, which I assume will be part of our discussions in Manchester 
(I'll be there BTW).
<http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark-02.txt>

I believe we really should get our views on basic questions like the 
relation between packet size and congestion sorted out better.

The draft has a split personality:
1/ a recommendation for now (afterall, it's an IETF TSVWG draft)
2/ stuff to set aside for future research (Section 7)

Section 7 "Open Issues & Next Steps" is devoted to discussing open 
issues concerning packet size & congestion. Complementing 
draft-irtf-iccrg-welzl-congestion-control-open-research-00.txt, it 
goes into depth on a couple of aspects of the issue, rather than 
trying to identify the breadth of issues.

Having written this, I now have a list of sub-questions to the question
"What type of drop was it?"
- transmission loss *OR* congestion *OR* policing?
- packet-rate congestion *OR* bit-rate congestion?  <<<--- this draft

I argue we should solve all these problems at once, not just 
"transmission vs congestion" on it's own.

I originally wrote the draft after I went through the welzl-eddy 
survey of cc RFCs to identify those RFCs with gaps/problems. I only 
found a couple. This draft is designed to fill a gap in the RED 
manifesto (RFC2309), which is also needed now for guiding the 
pre-congestion notificaton algo work in the PCN w-g.

Links and outline of changes are in the mail to tsvwg below.

Cheers

Bob

>Date: Tue, 26 Feb 2008 16:26:17 +0000
>To: "tsvwg IETF list" <[email-masked]>
>From: Bob Briscoe <[email-masked]>
>Subject: Updated: drop by packet size? draft-briscoe-tsvwg-byte-pkt-mark-02
>
>Folks,
>
>I've updated this one largely based on conversations at the last 
>IETF with Sally Floyd & (and a bit with Fred Baker). Changes from 
>-01 to -02 pasted at the end of this mail.
><http://www.ietf.org/internet-drafts/draft-briscoe-tsvwg-byte-pkt-mark-02.txt>
>
>Sally raised the question of whether I thought 'buffer carving' (as 
>used by certain Cisco routers for instance) was wrong, given it 
>advantaged small packets. With buffer carving, fixed sized buffers 
>are allocated in pools for different size packets.
>
>I've clarified that the reduced drop probability that small packets 
>get from such memory architectures is legitimate, given small 
>packets can fit into more buffers than large packets, so they 
>congest fixed sized buffers less.
>
>But I've also tried to explain better why designing an AQM to 
>deliberately further advantage small packets is incorrect and 
>potentially dangerous. To help, I've described a test for whether a 
>congestion control scales with packet size.
>
>My intent is for informational. I've had some off-list feedback 
>saying it really helped explain the issues, so pls go ahead and 
>bash. Packet size dependency is a tricky subject to get your head 
>round, so informed discussion would be useful.
>
>Cheers
>
>
>Bob
>
>/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
>
>Changes from Previous Versions [pasted from the draft]
>
>    To be removed by the RFC Editor on publication.
>
>    Full incremental diffs between each version are available at
>    <http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#byte-pkt-mark>
>    (courtesy of the rfcdiff tool):
>
>    From -01 to -02 (this version):
>
>          Abstract reorganised to align with clearer separation of issue
>          in the memo.
>
>          Introduction reorganised with motivating arguments removed to
>          new Section 2.
>
>          Clarified avoiding lock-out of large packets is not the main or
>          only motivation for RED.
>
>          Mentioned choice of drop or marking explicitly throughout,
>          rather than trying to coin a word to mean either.
>
>          Generalised the discussion throughout to any packet forwarding
>          function on any network equipment, not just routers.
>
>          Clarified the last point about why this is a good time to sort
>          out this issue: because it will be hard / impossible to design
>          new transports unless we decide whether the network or the
>          transport is allowing for packet size.
>
>          Added statement explaining the horizon of the memo is long
>          term, but with short term expediency in mind.
>
>          Added material on scaling congestion control with packet size
>          (Section 2.1).
>
>          Separated out issue of normalising TCP's bit rate from issue of
>          preference to control packets (Section 2.3).
>
>          Divided up Congestion Measurement section for clarity,
>          including new material on fixed size packet buffers and buffer
>          carving (Section 4.1.1 & Section 6.2.1) and on congestion
>          measurement in wireless link technologies without queues
>          (Section 4.2).
>
>
>
>
>____________________________________________________________________________
>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

____________________________________________________________________________
Bob Briscoe, <[email-masked]>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196 

From: [email-masked] (Eddy, Wesley M. (GRC-RCN0)[VZ])
Date: Wed Feb 20 14:21:23 2008
Subject: [Iccrg] meeting at IETF 71
Message-ID: <[email-masked]>

Following the Manchester meeting, we also decided to have a short
meeting
at IETF 71 in Philadelphia.  This has been put on the DRAFT schedule for
Monday afternoon (March 10) in the 1740-1950 timeslot.  I think we'll
have
a room that seats 40-50 people.  The main reason is that not all of the
RG
participants will be at PFLDNet, and we want to use the IETF meeting to
help progress our review of Compound TCP.  A short summary write-up of
what
the RG contributors have submitted so far will be coming out in the next
couple of days for discussion.

So far, the agenda we have planned looks like this:

1. RG Status - chairs (5 minutes)
2. Manchester recap for those who weren't there - chairs (10-15 minutes)
3. finishing draf-irtf-iccrg-cc-rfcs - W. Eddy (5 minutes)
4. Compound TCP Review - chairs and RG (30 minutes)
5. Solict reviews for CUBIC
Open time for presenting research (~1 hour)

If there are a few people that want to present short (15 minute)
research
presentations on new ideas they've been working on, please contact me
this
week.

See you in Philadelphia!

From: [email-masked] (Lachlan Andrew)
Date: Sat Feb 16 00:56:19 2008
Subject: [Iccrg] review of Compound TCP draft
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings Murari,

In the C-TCP specification, it is probably also worth pointing out
that the formula for  dwnd  only applies if  dwnd  is measured in
*packets*, not bytes.

Most RFCs seem to implicitly assume that the variable  cwnd  refers to
the number of bytes (even though it is incremented in multiples of
MSS).  For most flow control, this makes no difference.  However,
    dwnd = 1 packet    =>   dwnd^0.75 = 1
    dwnd = 1500 bytes  =>  dwnd^0.75 = 241
and so increase rule (3) in  draft-sridharan-tcpm-ctcp-01.txt  is much
more aggressive when  dwnd  is measured in packets.

Cheers,
Lachlan

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Ph: +1 (626) 395-8820    Fax: +1 (626) 568-3603
http://netlab.caltech.edu/~lachlan

From: [email-masked] (Dino-Martin LOPEZ-PACHECO)
Date: Mon Feb  4 14:57:36 2008
Subject: [Iccrg] About cautious use of unreliable feedback
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

I think that switching from an improved TCP to a Reno-like TCP when we 
believe that congestion is imminent (as CTCP does when RTT<baseRTT) is 
not the ideal solution, but today is the less worst solution (as Lachlan 
said, it returns to something not too broken).

I think the problem of protocols with early congestion detection is 
based on the fact that they deal with a "black blox" and the fact to 
predict a congestion does not mean necessarily to decrease the sending 
rate. Continuing with CTCP :-) imagine a case where one CTCP flow has 
been rerouted from a small-RTT path to a higher-RTT path. Since our CTCP 
flow will detect that current RTT >> baseRTT , it will behave as Reno 
TCP does, maybe wasting the resources.

We need maybe an AQM algorithm which doesn't advise senders to decrease 
the rate when a congestion is imminent (since in most of cases it could 
produce unfairness like ECN), but advise the senders not to decrease 
their rate if resources are not fully used (something like a positive 
ECN). Having this kind of positive ECN could allow CTCP to correctly 
update the baseRTT parameter in case of rerouting phenomenons (however 
new discussion about security would be suitable).

Dino M. LOPEZ P.
==========================================================
Ph.D Student
Laboratoire de l'Informatique et du Parall?lisme
ENS Lyon
46, All?e d'Italie   69364     Lyon Cedex 07     France
T?l +(33) 4 72 72 82 31     Fax +(33) 4 72 72 80 80

From: [email-masked] (Lachlan Andrew)
Date: Mon Feb  4 03:39:27 2008
Subject: [Iccrg] About cautious use of unreliable feedback
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings Cesar,

On 03/02/2008, Cesar Marcondes <[email-masked]> wrote:
> Finally, one can argue that, the router changes happen
> on another time granularity larger than the lifetime of a typical
> (HTTP) TCP connection.

You can argue that, but the algorithm should "work" in all cases, not
just the typical cases.  (By "work", I don't mean "work as intended",
but "not fail miserably".  CTCP doesn't work as intended if the
baseRTT increases without a timeout, but by returning to Reno, it
returns to something not too broken.)

Cheers,
Lachlan

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Ph: +1 (626) 395-8820    Fax: +1 (626) 568-3603
http://netlab.caltech.edu/~lachlan

From: [email-masked] (Michael Welzl)
Date: Mon Feb  4 02:57:25 2008
Subject: [Iccrg] About cautious use of unreliable feedback
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Thanks for sharing these thoughts. Imho, I don't see a problem on
> estimating path characteristics such as path delay and queueing delay
> by measuring RTT. First, this has been used for some time to trigger
> RTT timeout, as an example. Second, there are good aging mechanisms in
> place (exponential averages).

Well, that's a different thing - the RTO will adapt
when the minimum RTT increases, whereas the CTCP
baseRTT doesn't (to my understanding). Indeed EWMA
is a reasonable way of applying aging, so that would
fit here.

Anyway, I accept Lachlan's point about CTCP, where he
says that it's reacting like Reno when the baseRTT
goes up; this is may not be the ideal behavior, but
it's conservative enough then.

> But, the example you are bringing up (>> which includes switching to a
> new, possibly larger value) could be difficult to define with 100%
> certainty (perhaps, the right way is to signal that back using ECN). A

100% certainty will never exist  :)
But reasonable approaches can - as you said, aging mechanisms
like EWMA appear to do the trick (at least it seems that they
are good enough for RTO estimation).

> larger value of RTT for X duration, could just mean a steady
> cross-traffic passing the shared link and not a route change, isn't
> it? So, how to differentiate the two with 100%? In any case, most of
> the delay-based protocols are conservative to large RTT.

Cross traffic wouldn't give you a value which doesn't
fluctuate by more than Y% for the duration of X, which
is what I said. That's a better indicator.

> Another point is that route changes should result in packet loss while
> there is no convergence, since, packets are on the way to the router,
> and that would consistently trigger a retransmission timeout, cleaning
> up the baseRTT. Finally, one can argue that, the router changes happen
> on another time granularity larger than the lifetime of a typical
> (HTTP) TCP connection.

Agreed. I'm not sure if we can assume that route changes
will always result in packet loss - more complex things
than just a failure with ensuing IGP or EGP reconvergence
can happen inside a network, some of which could cause
the RTT to go up.

I don't know how often such "consistent RTT increase
without a lot of loss" things happen in practice,
though. Indeed, clearing baseRTT upon a timeout
is quite a sound thing to do.

Lachlan is right, this has turned into a CTCP
discussion. Well, it seems to me that CTCP fits
my criteria for being "cautious enough".

Cheers,
Michael

From: [email-masked] (Lachlan Andrew)
Date: Mon Feb  4 01:50:00 2008
Subject: [Iccrg] About cautious use of unreliable feedback
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings Michael,

If the baseRTT goes down, it is detected and CTCP keeps working
properly.  If the baseRTT goes up, CTCP becomes like Reno.  That is
why I said it "responds cautiously" to delay, as you suggested.  I
agree that the draft should explain more precisely how baseRTT is set,
but the actual algorithm is much less sensitive to it than Vegas was.
I interpreted "continually measure" as "take the minimum observed RTT
since it was last reset", the way Vegas does.

The only way that I can see that it is non-cautious is if it gets a
time-out when there is persistent congestion on one of the links, in
which case it over-estimates baseRTT.  However, even that is not a
real problem, because CTCP will detect the fluctuations in queue size
as a sign not to go into its "aggressive" mode.

Resetting baseRTT the way you propose makes CTCP more aggressive, but
has the possibility of making it too aggressive.  What it actually
does makes it never less aggressive than Reno, and only more
aggressive when it has very good evidence that it is safe to be.

While we're turning this into a discussion of CTCP, I think the Vista
implementation shows that it is counter-productive to be too worried
about having specifications that are very Reno-friendly and always
have benefits over Reno.  The current Vista implementation behaves so
extremely differently from the specification in the internet draft
that the details we have been discussing in assessing the draft fall
into the shadows.  (That statement is based on Doug's measurements of
Vista and my measurements of the Linux version of CTCP, which we can
see implements the spec.)

Similarly with BIC, there was a time when its Linux implementation was
*way* too aggressive due to a bug, rather than the spec itself.
Perhaps we should focus on making the algorithms and descriptions as
simple/specific and bug-tolerant as possible, rather than worrying
about whether they retain their benefit over Reno when the delay is
estimated incorrectly.

$0.02,
Lachlan

On 03/02/2008, Michael Welzl <[email-masked]> wrote:
> > CTCP sort of does that by reverting to Reno when its estimate of delay
> > is high.  RTT can't have severe negative-going spikes (because there
> > is an intrinsic minimum delay), and so the only noise to contend with
> > is positive-going noise,  which it handles conservatively.
>
> This minimum delay is called basertt in the draft. What
> happens to it when the connection is rerouted from a
> small-RTT path to a higher-RTT path?
>
> The only thing that I could find in the draft about setting
> this value is: "When a connection is started, basertt is updated
> to be the minimum RTT observed during the 3-way handshake. basertt
> is cleared and set to zero if a retransmission timeout is hit.
> It is continually measured and updated to track changing network
> conditions. "
>
> Does "continually measure" mean that we always look for the
> smallest possible value (always calculate the minimum) ?
>
> I assume it does. This alone will not help when the
> connection's minimum RTT generally increases because of
> a path change.
>
> Properly doing what I said would require the mechanism
> to continuously update basertt in an appropriate fashion,
> which includes switching to a new, possibly larger value.
> This would probably have to be done by detecting that
> it turned out to be the minimum, which was hit at
> least X times, during the last interval of Y RRTs
> (which brings about the difficulty of properly choosing
> X and Y, of course).
>
> Cheers,
> Michael
>
>

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Ph: +1 (626) 395-8820    Fax: +1 (626) 568-3603
http://netlab.caltech.edu/~lachlan

From: [email-masked] (Michael Welzl)
Date: Mon Feb  4 01:14:04 2008
Subject: [Iccrg] About cautious use of unreliable feedback
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> CTCP sort of does that by reverting to Reno when its estimate of delay
> is high.  RTT can't have severe negative-going spikes (because there
> is an intrinsic minimum delay), and so the only noise to contend with
> is positive-going noise,  which it handles conservatively.

This minimum delay is called basertt in the draft. What
happens to it when the connection is rerouted from a
small-RTT path to a higher-RTT path?

The only thing that I could find in the draft about setting
this value is: "When a connection is started, basertt is updated
to be the minimum RTT observed during the 3-way handshake. basertt
is cleared and set to zero if a retransmission timeout is hit.
It is continually measured and updated to track changing network
conditions. "

Does "continually measure" mean that we always look for the
smallest possible value (always calculate the minimum) ?

I assume it does. This alone will not help when the
connection's minimum RTT generally increases because of
a path change.

Properly doing what I said would require the mechanism
to continuously update basertt in an appropriate fashion,
which includes switching to a new, possibly larger value.
This would probably have to be done by detecting that
it turned out to be the minimum, which was hit at
least X times, during the last interval of Y RRTs
(which brings about the difficulty of properly choosing
X and Y, of course).

Cheers,
Michael

From: [email-masked] (Lachlan Andrew)
Date: Mon Feb  4 00:54:59 2008
Subject: [Iccrg] About cautious use of unreliable feedback
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Greetings Michael,

Good suggestion.

CTCP sort of does that by reverting to Reno when its estimate of delay
is high.  RTT can't have severe negative-going spikes (because there
is an intrinsic minimum delay), and so the only noise to contend with
is positive-going noise,  which it handles conservatively.

Cheers,
Lachlan

On 03/02/2008, Michael Welzl <[email-masked]> wrote:
> Hi all,
>
> This is just a thought that I'd like to share:
>
> There are plenty of proposals for doing better congestion
> control by using more feedback than standard TCP, and they
> generally have this problem that the mechanism can fail
> due to noise (e.g. when such feedback is wrongly interpreted).
>
> So we end up with proposals for TCP variants which are
> shown to be a lot better than standard TCP (or other
> competitors) under certain conditions, but may not be very
> realistic for wide scale deployment, and standard TCP which
> doesn't use such extra feedback at all.
>
> What we seem to be missing are proposals which strike
> a middle ground, i.e. use additional feedback, but in
> a more cautious way.
>
> Let's assume that TCP X uses an RTT increase as an indication
> of a growing queue, and hence it reacts, e.g. by increasing
> the rate more conservatively or even decreasing it.
> TCP X would then react to effects such as link layer ARQ,
> and more severe problems such as route flapping would
> lead to completely wrong behavior.
>
> Now, why doesn't someone propose TCP Y, which is more
> stable against sporadic fluctuations by reacting IFF
> the RTT has not changed by more than a certain percentage
> for a long time (indicating that no route flapping occurred,
> and that there are no interactions on a wireless link),
> and the RTT has begun to gradually increase?
>
> Wouldn't that be a much more realistic thing to do?
>
> Sure, TCP Y would react to route flapping or link
> layer ARQ as it occurs for the first time, but that
> might be just the right thing to do - the idea would
> be to stop using this kind of feedback until it
> stabilizes again.
>
> I took queing delay as an example because this is
> quite a common type of feedback to use, but the point
> that I'm trying to make applies to all kinds of
> additional feedback (e.g., trying to get a
> bandwidth estimate with packet pairs or trains,
> whatever).
>
> I'd be interested in your thoughts. Wouldn't that
> be a good way to move forward, especially for TCP++
> proposals that should take the ICCRG - TCPM path?
>
> I haven't personally reviewed one of our drafts yet,
> but if I was to review TCP X above, I would vote against
> it unless the authors can show that it works in the
> presence of route flapping or heavy RTT fluctuations
> from link layer ARQ.
>
> Cheers,
> Michael
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Ph: +1 (626) 395-8820    Fax: +1 (626) 568-3603
http://netlab.caltech.edu/~lachlan

From: [email-masked] (Michael Welzl)
Date: Mon Feb  4 00:27:00 2008
Subject: [Iccrg] About cautious use of unreliable feedback
Message-ID: <[email-masked]>

Hi all,

This is just a thought that I'd like to share:

There are plenty of proposals for doing better congestion
control by using more feedback than standard TCP, and they
generally have this problem that the mechanism can fail
due to noise (e.g. when such feedback is wrongly interpreted).

So we end up with proposals for TCP variants which are
shown to be a lot better than standard TCP (or other
competitors) under certain conditions, but may not be very
realistic for wide scale deployment, and standard TCP which
doesn't use such extra feedback at all.

What we seem to be missing are proposals which strike
a middle ground, i.e. use additional feedback, but in
a more cautious way.

Let's assume that TCP X uses an RTT increase as an indication
of a growing queue, and hence it reacts, e.g. by increasing
the rate more conservatively or even decreasing it.
TCP X would then react to effects such as link layer ARQ,
and more severe problems such as route flapping would
lead to completely wrong behavior.

Now, why doesn't someone propose TCP Y, which is more
stable against sporadic fluctuations by reacting IFF
the RTT has not changed by more than a certain percentage
for a long time (indicating that no route flapping occurred,
and that there are no interactions on a wireless link),
and the RTT has begun to gradually increase?

Wouldn't that be a much more realistic thing to do?

Sure, TCP Y would react to route flapping or link
layer ARQ as it occurs for the first time, but that
might be just the right thing to do - the idea would
be to stop using this kind of feedback until it
stabilizes again.

I took queing delay as an example because this is
quite a common type of feedback to use, but the point
that I'm trying to make applies to all kinds of
additional feedback (e.g., trying to get a
bandwidth estimate with packet pairs or trains,
whatever).

I'd be interested in your thoughts. Wouldn't that
be a good way to move forward, especially for TCP++
proposals that should take the ICCRG - TCPM path?

I haven't personally reviewed one of our drafts yet,
but if I was to review TCP X above, I would vote against
it unless the authors can show that it works in the
presence of route flapping or heavy RTT fluctuations
from link layer ARQ.

Cheers,
Michael

From: [email-masked] (Lisong Xu)
Date: Fri Feb  1 04:23:36 2008
Subject: [Iccrg] Comments to CUBIC
Message-ID: <[email-masked]>

Dear all,

Thank you for those of you who have sent us your comments about CUBIC. 
We plan to update and revise the CUBIC Internet draft. But before we 
start revising it, we would like to find out whether there are any other 
comments about CUBIC.

Please send your comments to me at [email-masked] and also to Injong at 
[email-masked].

Thank you!
Lisong

-- 
Lisong Xu, Assistant Professor
Computer Science & Engineering
University of Nebraska-Lincoln
http://cse.unl.edu/~xu

From: [email-masked] (Michael Welzl)
Date: Fri Feb  1 03:50:33 2008
Subject: [Iccrg] Preliminary agenda for the next meeting
Message-ID: <[email-masked]>

Dear all,

Here's the first version of the agenda for our next
meeting (Manchester, with Pfldnet 2008:
http://www.hep.man.ac.uk/PFLDnet2008/  - this is
the page to check for all logistics details).

>From the input that I got, it is now clear that this
meeting will only take a day, and that day will be
Wednesday, the 5th of March. The PFLDNet reception
will take place on the same day, after our meeting.

The ICCRG meeting agenda is below and also at
http://www3.tools.ietf.org/group/irtf/trac/wiki/Agenda08

09:00 - 09:15 Michael Welzl: Welcome and agenda bashing
09:15 - 10:15 Volker Hilt: SIP overload control
10:15 - 10:45 Dimitri Papadimitriou: Open research issues in Internet
congestion control
10:45 - 11:00 Break
11:00 - 12:00 Discussion of open issues in Internet congestion control
12:00 - 13:00 Lunch
13:00 - 13:30 Injong Rhee: CUBIC
13:30 - 14:00 Doug Leith: CTCP evaluation results
14:00 - 14:30 Lachlan Andrew: Getting more information from ECN bits
15:15 - 15:30 Break
15:30 - 16:30 Open discussion about future work

---

Some explanations / comments from my side:

(as Lars also pointed out to me, but that's a 100% match
with my personal opinion) - the congestion control community
should not be stuck with TCP all the time; we really should
try to look over the fence and see where else congestion
control is needed. This is a part of the role that the
"open issues in Internet CC." draft (which Dimitri
will present) can take, and Volker Hilt's talk fits in
there just perfectly.

This is why we have the long slot about discussing open
issues. We could use it to take another look at the
open issues we already identified previously, and Lars
offered to present some open issues in cc. from elsewhere
in the IETF, which would also fit in that time slot.

CUBIC, in the afternoon, is about the current state of
the draft. Injong (or a colleague - he wasn't sure if
he'll come himself, but somebody will definitely be there)
should present the draft, comments he got, and how he
intends to address them.

Let me know if you have any comments - and, as you
can tell, there would still be some time to squeeze
in a short talk or two in the afternoon, if somebody
wants to. The open discussion doesn't have to be that
long (do we need it at all? I just put it there in
case we want to go on discussing things...), and we
could end slightly later (although not a lot).

--------

PARTICIPATION:

If your name is not on the agenda, and you would to
participate (and your name is not Filipe or Lars  :-)
because these are the two that I already know about),
drop me a line so I can put you on the list.

Cheers,
Michael