Subject: [Iccrg] Next ICCRG meeting: Agenda
From: [email-masked] (Michael Welzl)
Date: Tue Jan 29 06:35:25 2008

wow,

i never had so few requests for agenda time slots before.
this is a bit disappointing... again, let's plan this
fast, so if you would like to give a talk at this meeting,
please let me know!

cheers
michael

On Fri, 2008-01-25 at 10:19 +1100, Michael Welzl wrote:
> Hi again,
> 
> Let me add: since this is directly before the IETF,
> attending both will be difficult enough to book for
> some of us, so we need to finish the schedule really,
> really fast. Just let me know about proposed slots
> ASAP, please.
> 
> Cheers,
> Michael
> 
> PS: this
> 
> > evolves, we could include the day before too (4 May).
> 
> was a mistake - of course it's March  :)
> 
> 
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Michael Welzl)
Date: Thu Jan 24 23:19:45 2008
Subject: [Iccrg] Next ICCRG meeting: Agenda
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi again,

Let me add: since this is directly before the IETF,
attending both will be difficult enough to book for
some of us, so we need to finish the schedule really,
really fast. Just let me know about proposed slots
ASAP, please.

Cheers,
Michael

PS: this

> evolves, we could include the day before too (4 May).

was a mistake - of course it's March  :)

From: [email-masked] (Michael Welzl)
Date: Thu Jan 24 07:14:16 2008
Subject: [Iccrg] Next ICCRG meeting: Agenda
Message-ID: <[email-masked]>

Hi all,

As announced previously, the next ICCRG meeting will
be co-located with Pfldnet just like last year.
This time, it will be in Manchester, UK.
For details about the place etc., please check the
pfldnet webpage at: http://www.hep.man.ac.uk/PFLDnet2008/

The date is shifting a little bit: PFLDNet will have
a reception on the evening of 5 March, so we should have
our meeting on that same day to allow for a smooth
transition for those ( = presumably most ) of us who will
want to attend both events. Depending on how the agenda
evolves, we could include the day before too (4 May).

If you have any topics that you would like to discuss
at that meeting, send me a short message by the end
of January with the title of your talk and any other
information you would like to add; also, let me know
how much time you'd like to have for your talk.

Thanks!

Cheers,
Michael

From: [email-masked] (Chamil Kulatunga)
Date: Thu Jan 17 17:30:20 2008
Subject: [Iccrg] Use of CUBIC in Rate-based Congestion Control
Message-ID: <[email-masked]>

Dear Rhee,

In TFRC throughput equation, RTT stays in the denominator (lower part). 
When the bottleneck queue fills, RTT increases. Then the sender reduces 
its rate according to the developing queue when moves from one 
loss-event to the next. Therefore queuing delay is considered.

But in CUBIC, RTT stays in the numerator (upper part). According to RTT 
increase due to queuing delay, the sender increases the rate after a 
loss-event until it meet the next loss.

This may give some contradictory representation if used in any 
equation-based congestion control. Will this restrict using CUBIC with 
equation-based approaches?

Chamil Kulatunga
Communications and Imaging Research Group
Department of Engineering
University of Aberdeen
Aberdeen, AB24 3UE
United Kingdom

Tel: + 44 1224 272813
Fax: + 44 1224 272497

From: [email-masked] (Douglas Leith)
Date: Wed Jan 16 15:46:29 2008
Subject: [Iccrg] ctcp draft
Message-ID: <[email-masked]>

Some additional comments on the ctcp internet draft.   In trying to  
write out the ctcp algorithm as pseudo-code one or two issues have  
come to light that I think would benefit from clarification.

1.  How is rtt to be measured ?  Is it the standard rtt measurement  
as per RFC 1323 and already used for RTO ?  Or does ctcp require  
something else e.g. with some kind of filtering used.

2.  How is baseRTT measured ?  Presumably its the lowest rtt measured  
over the connection lifetime, or something like that, but it would be  
helpful to make this explicit since its so central to the operation  
of the delay-based component of the algorithm.

3.  dwnd is updated each "round", but a "round" is not defined.  I  
presume a round means something like an update once per RTT (as per  
Vegas) but maybe that's wrong.  If it is once per RTT, should that be  
once per cwnd worth of packets or really once per RTT (and which RTT ?).

4.  How is slow-start handled ?    E.g. what does dwnd to during slow- 
start,  when do we exit slow-start (when the reno cwnd reaches  
ssthresh, or when the overall cwnd reaches ssthresh, or something else).

Doug

Hamilton Institute
www.hamilton.ie

From: [email-masked] (Michael Welzl)
Date: Thu Jan 10 13:00:24 2008
Subject: [Iccrg] A message to authors of PFLDNet papers
Message-ID: <[email-masked]>

Dear all,

I am writing this email in the function of Pfldnet TPC
co-chair, not ICCRG co-chair or even just Michael   :-)

This year, based on the explanation on the PFLDNet website:
http://www.hep.man.ac.uk/PFLDnet2008/
it was required to submit papers via email.

We now have a concern that some submissions might not have
been received by us due to spam filters. Maybe email submission
was not the best idea...

Anyway, in an effort to restrain any damage, we would like
to inform you that authors of papers who submitted to Pfldnet'08
should have received a confirmation email. If you submitted
a paper but never received a confirmation email, by all means
resubmit it please - or just send it to one of us organizers,
who will confirm reception to you.

We apologize for the trouble.

Best regards,
Michael Welzl

From: [email-masked] (Lisong Xu)
Date: Thu Jan 10 05:02:16 2008
Subject: [Iccrg] Comments about CUBIC draft
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Dear Dino,

Sorry for my late response. Thank you for your interest and comments on 
CUBIC. Please see my reply below.

Dino-Martin LOPEZ-PACHECO wrote:
> Hi all,
> 
> My name is Dino and I'm a new member in this group.
> 
> I have read the draft about the CUBIC protocol and here you are some
> comments that I think can be useful for future discussions.
> 
> ****** Comments concerning the writing quality ******
> 
> The CUBIC draft  (draft-rhee-tcpm-cubic-00.txt) is in general clear and
> understandable. But
> 
> 1. The draft is missing standards language (SHOULD, MUST, etc)

Thanks. Yes, we will revise the draft accordingly.

> 2. The used parameters must be clearly documented (the C parameter needs
> more explanation - why C = 0.4?).

Since it is hard to give the mathematical proof in the draft, we give 
only the intuitive reason in the draft. More detailed explanation and 
analysis are given in our CUBIC paper.

> 3. In Section 2.2 (TCP-friendly region) the authors write: "If cwnd is
> less than W_tcp(t), then the protocol is in the TCP friendly region...",
> while in the paper "CUBIC: A New TCP-Friendly High-Speed TCP Variant",
> the authors say that CUBIC is in the TCP-friendly region when W(t+RTT)
> is less than W_tcp(t). Since cwnd is not equal to W(t+RTT) I think both
> arguments are different and a clarification about this point is needed.

Our CUBIC paper reads "If Wtcp is larger than Wcubic (in eqn. 1), then 
we set the window size to Wtcp.", which is consistent with the CUBIC draft.

> 
> ****** Comments concerning the CUBIC protocol mechanisms ******
> 
> CUBIC in an extension of the current standard TCP, to improve the
> performance of TCP in wire-based large bandwidth * delay product
> networks. The new mechanisms proposed by CUBIC modify only the window
> increase function in the sender side, to get high link utilization in a
> large variety of network conditions. Thus, CUBIC does not impact the
> Internet security and reacts as standard TCP in case of congestion
> collapses, routing changes, link disconnections, intermittent links or
> mobility events.
> 
> Moreover, CUBIC directly impact the throughput and the fairness. On the
> one hand :
> 
> 1. Some experiments (http://netsrv.csc.ncsu.edu/highspeed/) show that
> CUBIC flows sharing the bottleneck converge to the fairness point, but
> the needed time for converging can be large. For instance, in the paper
> "Experimental Evaluation of CUBIC-TCP", the authors show that 2 flows
> could need up to 500s before getting fairness in a 500Mbps bottleneck
> link, with an RTT of 200ms. This phenomenon can be also observed in the
> experiences presented in the web address before cited.

Injong has written a rebuttal to "Experimental Evaluation of CUBIC-TCP", 
which discusses and explains the results shown in that paper. Basically,
   1. There is no absolute performance metric for "slow" and "fair" that 
are all relative terms. Performance evaluation without proper comparison 
with other protocols may be misleading.
   2. We should discuss whether an observation is a behavior of a 
protocol in a specially designed case or in a more realistic case.
   3. We should discuss whether an observation is an unique behavior of 
a highspeed TCP variant, or a common behavior of all TCP variants.

For more information, please refer to 
http://www.csc.ncsu.edu/faculty/rhee/Rebuttal-LSM-new.pdf

> 2. Experiments about CUBIC show also that, in many cases, CUBIC flows
> degrade the performance of standard TCP. The unfairness between CUBIC
> and TCP increases as the RTT increases
> (http://netsrv.csc.ncsu.edu/wiki/index.php/Testing_between_Korea_and_Japan,
> http://netsrv.csc.ncsu.edu/highspeed/).

This is not "the unfairness between CUBIC and TCP", and it should be 
"the difference between CUBIC and TCP". The reason is that TCP cannot 
efficiently use the available bandwidth in a network with a long RTT, 
and CUBIC is designed to achieve more throughput than TCP in such a network.

Thanks
Lisong

> 
> But on the other hand, there are some important arguments to consider
> CUBIC as a congestion protocol which can be safely deployed in the Internet:
> 
> 1.- It has been proved mathematically and experimentally that CUBIC is
> less aggressive than High Speed TCP, and HSTCP hasn't been known
> to exhibit severe issues in deployment or testing experiences (HSTCP has
> already an experimental RFC status).
> 2.- Several experiments have shown that CUBIC is less aggressive than
> BIC, and BIC is used by most Linux-based systems since year 2005.
> (Currently I don't know severe problems derived from the use of BIC in
> Internet...)
> 
> Even if high speed protocols, like High Speed TCP, BIC or CUBIC, can
> potentially introduce serious congestion and unfairness problems due to
> their aggressiveness, the throughput of such high speed protocols stay
> limited by the TCP buffer size (and the link capacity in the end hosts).
> Now, we must consider that in most cases, such buffer size is
> initialized with a very small value (e.g. the default maximum TCP buffer
> size is 128KB in most Linux-based systems). Thus, I believe the damaged
> caused by CUBIC to standard TCP flows, which is less aggressive than
> HSTCP and BIC, will be very limited. Therefore, I believe this protocol
> can be safely deployed in the Internet.
> 
> ******************
> 
> Cheers,
> 
> Dino M. LOPEZ P.
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
> 

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