Subject: [Iccrg] Separate header checksums and WiFi
From: [email-masked] (Gorry Fairhurst)
Date: Tue Feb 27 18:54:56 2007

I'm a little late in replying, but would like to offer a few thoughts 
myself on this:

It's good to see real results and to understand how the
have been obtained and what their implications are. Thanks Michael!

1)  The doubts I expressed related to the use of existing PHY interfaces 
for this,

2)  At one point the thesis makes the statement that:

"In links without such partial
detection capabilities, errored frames always have to be dropped. It is 
also specified that
implementing partial error detection only makes sense on error-prone 
links, i.e. radio links. "

- Those last two words are in my opinion the key ones. This method is 
meant to be a
cross-layer optimisation, where we have seen it have merit, we have 
needed to go much
lower than the link adaptation layer to modify the waveform itself, or 
at least the way in
which it is used. It turns out, that design decisions made early in the 
design of the PHY
have a significant bearing on the likely success of UDP-Lite. Examples 
include the choice
of FEC, the power-budget used (scheduling/power control), and the way in 
which
fragmentation is handled.

- If you could devise a codec for multimedia that was (more) 
error-tolerent, then you
could propose to do the trade-off differently, and that's where I see 
use for UDP-Lite,
and hence it's applicability (?) to DCCP also.

Until links support UDP-Lite, we won't have applications that can take 
advantage
of this... while links are designed to be quasi-error-free (QEF), we 
don't provide an
incentive for media codecs to be designed in this way either, so the 
tendency is to make
codecs that have less error-tollerence, but higher efficiency in a QEF 
channel.... 
We'll hopefully look at some of these next year, if anyone would like to 
join us,
 that would be fine...

3) I think that using this with TCP could present a difficult 
trade-off., and I'd agree
that this seems an unlikely place to find an application for this type 
of method.

Gorry Fairhurst

P.S. I enjoyed reading the thesis!

Michael Welzl wrote:

>Dear all,
>
>A long time ago, at the San Diego IETF meeting in August 2004,
>I presented an idea called "Corruption Notification Options"
>(a proposal which is some sort of a refined specification of
>the TCP HACK idea) to the TCPM group.
>
>The group's feedback was that this is useless, as errors
>occur in such a clustered fashion that you wouldn't see
>any packets with an intact header but erroneous payload
>(which is the only situation where the scheme would
>yield any benefit). I think that it was Gorry Fairhurst
>who said this.
>
>I figured that the only convincing way to prove him
>wrong is to actually do a real-life test. I did, and
>proved him right  :)  that is, disabling checksums for
>parts of packets doesn't yield much of a benefit in
>WiFi networks, where it seems that frames are delivered
>in an all-or-nothing fashion.
>
>Doing this test requires patching the device driver (to
>disable the link layer CRC), and above all, finding a good
>student - all of this took quite some time, but now it's
>over, and the documentation can be found at:
>http://www.welzl.at/research/projects/corruption/
>(bottom of the page)
>
>I learned my lesson, and thought I'd share it with you -
>but this result only concerns WiFi. I'll keep this as a
>low-priority "background" project and may take a closer
>look at other link layers one day... in any case, that
>topic still interests me, and I can't believe that it
>wouldn't be possible to get a benefit out of such a scheme.
>
>
>I'm sending this note to TCPM, TSVWG and DCCP because there
>are similar mechanisms there (DCCP: the Data Checksum option; SCTP:
>http://www.ietf.org/internet-drafts/draft-stewart-sctp-pktdrprep-06.txt
>although I just noticed that this is apparently not a WG item...
>still, it's SCTP related).
>
>This note also goes to ICCRG, because I think that this should
>be the place for related discussions (in fact Lachlan Andrew
>will give us a related talk at our upcoming meeting:
>http://www1.tools.ietf.org/group/irtf/trac/wiki/Agenda )
>
>
>Cheers,
>Michael
>
>
>_______________________________________________
>Iccrg mailing list
>[email-masked]
>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>
>
>  
>

From: [email-masked] (Lachlan Andrew)
Date: Sat Feb 24 03:05:36 2007
Subject: [Iccrg] feedback on draft-irtf-tmrg-metrics?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Greetings,

On 22/02/07, Eric Coe <[email-masked]> wrote:
> o Page 15 Section 3.5  Title and concept of "failures"
>      I'm not sure that "failures" makes sense here. This whole section
> really deals with "Misbehaving Users". Looking at the examples given:
>
>     o "Failures of the routers in using explicit feedback to end-nodes
>        or failures of end-nodes to follow the prescribed protocols."

I agree that "failure" suggests hardware failure, but I think it is referring
to buggy implementations, rather than either non-capable implementations
or deliberately trying to circumvent the mechanisms.  Perhaps it could be

"Incorrect behavior of the routers in using explicit feedback to end-nodes
or end-nodes not exactly following the prescribed protocols."

$0.02
Lachlan

-- 
Lachlan Andrew  Dept of Computer Science, Caltech
1200 E California Blvd, Mail Code 256-80, Pasadena CA 91125, USA
Phone: +1 (626) 395-8820    Fax: +1 (626) 568-3603

From: [email-masked] (eBay Member)
Date: Sat Feb 24 00:36:16 2007
Subject: [Iccrg] Message from eBay Member Regarding Item #320080310929
Message-ID: <[email-masked]>

An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070223/ea3aa045/attachment.html
>From [email-masked]  Sat Feb 24 01:48:48 2007
From: [email-masked] (Sally Floyd)
Date: Sat Feb 24 01:50:56 2007
Subject: [Iccrg] feedback on draft-irtf-tmrg-metrics?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Eric -

Many thanks for the feedback.

> Comments on the above draft.
>
> o  TYPO: Page 5 under revision "draft-irtf-tmrg-metrics-01a.txt"
>      second bullet item should be "Sean Moore" not Seam Moore.

Thanks, fixed.

> o  Page 14 Paragraph BEFORE section 3.4 first sentence.
>    Currently reads:
>    "...concern for environments with high-bandwidth flows."
>
>    Should it read:
>    "...concern for environments with high-bandwidth delay flows."
>
>    I think it's the tricky combo of high-bandwidth and long delay that
>    makes convergence to fairness problematic. Thoughts?

I changed it to "high-bandwidth long-delay flows".

> o  Page 14 Paragraph BEFORE section 3.4 second sentence.
>    Currently reads:
>    "...between two existing flows after a sudden change such as a 
> change in link capacity on a wireless link."
>
>    Suggestion to be more explicitly general (really):
>    "...between two existing flows after a sudden change in network 
> [characteristics|conditions], such as a change in link capacity on a 
> wireless link."

I left it how it was, because I thought it was sufficiently clear.

> o Page 15 Defining Goodput. First sentence
>    "...is defined as the fraction of useful data from all of the data
> delivered."
>
>    Should this be:
>    "...is defined as the fraction of useful data from all of the data 
> sent."
>
>     Since the following sentence further defines high goodput as
> efficient use of spectrum... data can be sent, and then NOT delivered
> (for various reasons) which effects things like efficient spectrum use 
> and buffer occupancy. The first definition does not fully capture the 
> effect.

Yep, I changed it.

> o Page 15 Section 3.5  Title and concept of "failures"
>     I'm not sure that "failures" makes sense here. This whole section
> really deals with "Misbehaving Users". Looking at the examples given:
>
>    o "Failures of the routers in using explicit feedback to end-nodes
>       or failures of end-nodes to follow the prescribed protocols."
>
> If the routers are suppose to provide explicit feedback and they are 
> not, they are "misbehaving" and if end-nodes are not following 
> prescribed protocols then they are also "misbehaving". Failure to 
> "follow" protocol standards is a form of misbehaving. I tend to think 
> of failures as more in the terms of "dead nodes", maybe more like 
> faults.
>
> If instead we really mean "non-capable nodes" e.g. non-XCP routers on 
> a XCP path. Then maybe a title more like "Robustness to Non-capable 
> and to  Misbehaving Users"

I left this one how it was, because I thought it was ok.

Many thanks.

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

From: [email-masked] (Lars Eggert)
Date: Thu Feb 22 17:36:00 2007
Subject: [Iccrg] TSVAREA presentation slots for Prague
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

please send agenda requests for TSVAREA in Prague to tsv- 
[email-masked], including:

	title/topic
	presenter
	requested time

The purpose of the TSVAREA meeting is to inform about and discuss  
important issues, developments and work within the transport area or  
outside work that impacts the transport area. In contrast to TSVWG,  
TSVAREA does not produce any documents. TSVAREA can include tutorial- 
style talks on tranport topics, maybe based on related IRTF or other  
research work. Again, we encourage relevant presentations from both  
within the transport area and from outside parties, such as other  
IETF WGs or the IRTF.

Thanks,
Lars

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2446 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070222/50052634/smime.bin
>From [email-masked]  Thu Feb 22 20:52:16 2007
From: [email-masked] (Eric Coe)
Date: Thu Feb 22 20:56:32 2007
Subject: [Iccrg] feedback on draft-irtf-tmrg-metrics?
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Sally Floyd wrote:
> "Metrics for the Evaluation of Congestion Control Mechanisms",
>  internet-draft draft-irtf-tmrg-metrics-07.txt, is available from:
>   http://www.icir.org/tmrg/draft-irtf-tmrg-metrics-07.txt
>   http://www.icir.org/tmrg/draft-irtf-tmrg-metrics-07.ps
> 
> This draft has finished review within the TMRG (Transport
> Modeling Research Group), and is ready to be passed to
> the IRTF for review and publication.  However, before I pass
> this to the IRTF, this is to pass it by ICCRG for feedback.
> If anyone would like to read it and give feedback, feedback
> would be appreciated in the next two weeks (that is,
> by March 6).  After that, I will forward the draft to IRTF
> for review and publication as an Informational RFC.

Comments on the above draft.

o  TYPO: Page 5 under revision "draft-irtf-tmrg-metrics-01a.txt"
      second bullet item should be "Sean Moore" not Seam Moore.

o  Page 14 Paragraph BEFORE section 3.4 first sentence.
    Currently reads:
    "...concern for environments with high-bandwidth flows."

    Should it read:
    "...concern for environments with high-bandwidth delay flows."

    I think it's the tricky combo of high-bandwidth and long delay that
    makes convergence to fairness problematic. Thoughts?

o  Page 14 Paragraph BEFORE section 3.4 second sentence.
    Currently reads:
    "...between two existing flows after a sudden change such as a 
change in link capacity on a wireless link."

    Suggestion to be more explicitly general (really):
    "...between two existing flows after a sudden change in network 
[characteristics|conditions], such as a change in link capacity on a 
wireless link."

o Page 15 Defining Goodput. First sentence
    "...is defined as the fraction of useful data from all of the data
delivered."

    Should this be:
    "...is defined as the fraction of useful data from all of the data 
sent."

     Since the following sentence further defines high goodput as
efficient use of spectrum... data can be sent, and then NOT delivered
(for various reasons) which effects things like efficient spectrum use 
and buffer occupancy. The first definition does not fully capture the 
effect.

o Page 15 Section 3.5  Title and concept of "failures"
     I'm not sure that "failures" makes sense here. This whole section
really deals with "Misbehaving Users". Looking at the examples given:

    o "Failures of the routers in using explicit feedback to end-nodes
       or failures of end-nodes to follow the prescribed protocols."

If the routers are suppose to provide explicit feedback and they are 
not, they are "misbehaving" and if end-nodes are not following 
prescribed protocols then they are also "misbehaving". Failure to 
"follow" protocol standards is a form of misbehaving. I tend to think of 
failures as more in the terms of "dead nodes", maybe more like faults.

If instead we really mean "non-capable nodes" e.g. non-XCP routers on a 
XCP path. Then maybe a title more like "Robustness to Non-capable and to 
  Misbehaving Users"

-eric

From: [email-masked] (Sally Floyd)
Date: Wed Feb 21 01:18:56 2007
Subject: [Iccrg] feedback on draft-irtf-tmrg-metrics?
Message-ID: <[email-masked]>

"Metrics for the Evaluation of Congestion Control Mechanisms",
  internet-draft draft-irtf-tmrg-metrics-07.txt, is available from:
   http://www.icir.org/tmrg/draft-irtf-tmrg-metrics-07.txt
   http://www.icir.org/tmrg/draft-irtf-tmrg-metrics-07.ps

This draft has finished review within the TMRG (Transport
Modeling Research Group), and is ready to be passed to
the IRTF for review and publication.  However, before I pass
this to the IRTF, this is to pass it by ICCRG for feedback.
If anyone would like to read it and give feedback, feedback
would be appreciated in the next two weeks (that is,
by March 6).  After that, I will forward the draft to IRTF
for review and publication as an Informational RFC.

Many thanks,

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

From: [email-masked] (Aaron Falk)
Date: Mon Feb 12 18:46:24 2007
Subject: [Iccrg] webcast & jabber room information for the ICCRG meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Session 1 ended early due to an operator error.  We added a short  
session before Session 2 from 10:20 - 10:50am PDT to carry one talk:

http://webcasterms.isi.edu/mediasite/viewer/? 
peid=236bf937-428d-4a51-986e-18bb8c57be74

--aaron

On Feb 11, 2007, at 11:11 AM, Aaron Falk wrote:

> A webcast will be available for ICCRG meeting at the URLs below.   
> My understanding is that the video will be available for offline  
> viewing as well.  Times are in US PDT.  (I haven't used the webcast  
> services at ISI before and there may be hiccups.  Please be  
> patient. :)
>
> Also, possibly useful for questions from webcast viewers, a jabber  
> room for groupchat will be available at [email-masked].   
> Information on Jabber clients, accounts, and the IETF jabber server  
> is available at <http://www.ietf.org/meetings/text_conf.html>.   
> Free accounts are available at <http://www.postel.org/jabber>.
>
> --aaron
>
> ------------------------------------------
>
> Day 1 02/12/2007
>
> Session 1 9:00am - 10:45am:
> http://webcasterms.isi.edu/mediasite/viewer/? 
> peid=64846f9b-1b4c-4775-84f4-c06775e547c8
>
> Session 2 11:00am - 1:30pm:
> http://webcasterms.isi.edu/mediasite/viewer/? 
> peid=228d290b-8196-485f-bb9d-ee5b1f168019
>
> Session 3  1:45pm - 3:25pm:
> http://webcasterms.isi.edu/mediasite/viewer/? 
> peid=05590890-2e35-488d-81bb-66e6428b6470
>
> Session 4  3:30pm - 6:00pm:
> http://webcasterms.isi.edu/mediasite/viewer/? 
> peid=95c9aff9-732f-4d3d-915c-e2df43b809a1
>
>
> Day 2 02/13/2007
>
> Session 1: 9:00am - 10:30am:
> http://webcasterms.isi.edu/mediasite/viewer/?peid=4aa00350- 
> f96f-41cd-b2e8-1c0b904288f1
>
> Session 2: 10:45am - 1:00pm:
> http://webcasterms.isi.edu/mediasite/viewer/? 
> peid=bb9e7bad-3838-451d-bbe3-9b319d3b0ec8
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Bob Briscoe)
Date: Mon Feb 12 18:46:24 2007
Subject: [Iccrg] Slides: Flow rate fairness: Dismantling a religion
Message-ID: <[email-masked]>

Michael,

Here's the slides for the slot at the ICCRG tomorrow Tuesday:
>11:30 - 12:15 PST  Bob Briscoe: Flow Rate Fairness: Dismantling a Religion
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/present.html#0702rateFairDis>

PS. The first of the spare slides is about a usable definition of congestion.
p(t) = excess_load(t) / offered_load(t)

PPS. If you follow the "paper & Internet Draft" link there:
<http://www.cs.ucl.ac.uk/staff/B.Briscoe/pubs.html#rateFairDis>

you get a link to the I-D on which this is based 
<draft-briscoe-tsvarea-fair-00.pdf> and a paper of the same title (to 
appear) that I've just posted. It adds critiques of the fairness in the 
main popular cc schemes (TCP, TFRC, XCP).

Bob

____________________________________________________________________________
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] (S. Keshav)
Date: Tue Feb 13 15:32:16 2007
Subject: [Iccrg] Slides from my talk
Message-ID: <[email-masked]>

are attached...

keshav
-------------- next part --------------
A non-text attachment was scrubbed...
Name: congestion.pdf
Type: application/pdf
Size: 47636 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20070212/ebd5c90a/congestion-0001.pdf
>From [email-masked]  Mon Feb 19 10:40:00 2007
From: [email-masked] (Michael Welzl)
Date: Mon Feb 19 10:42:08 2007
Subject: [Iccrg] Meeting material
Message-ID: <[email-masked]>

Dear all,

Below you'll find the minutes from our meeting (thanks to Kashif).
The slides are available from:
http://www1.tools.ietf.org/group/irtf/trac/wiki/Agenda

Cheers,
Michael

----

IRTF ICCRG meeting, 12/13 February 2007, ISI, Marina Del Rey, CA USA

Day-1
Session # 1:

Michael Welzl: "Current State of ICCRG"

Additions in existing RFCs and drafts
Role of IETF in Congestion Control issues
Move to high-speed TCPs?

Comments and issues raised by Aaron Falk, Lars Eggert, Bob Briscoe,
Larry Dunn, Ted Faber
Tim Shepard (about current cc survey draft): how to distinguish between
QoS and CC?
Michael Welzl: group should suggest the inclusion of a particular RFC if
desired

Keshav: "What is Congestion and what is congestion control?"

Congestion is reduction in utility due to overload in networks that
support both spatial and temporal multiplexing but no reservation.
Solution schemas exist, but inherently complex. 
Delays due to temporal multiplexing were discussed. Delays due to small
buffers.

Comments and issues raised by Bob Briscoe, Tim Shepard, Doan Hoang

Chris Christou: "The role of the Transport Layer in Delivering an
Assured Elastic Service:
GIG Network types, GIG converged Services and Precedence"

Behavioral model for an assured elastic service.
Focus on implementing the Assured Elastic Service.
Requirements for the assured elastic service and the work to date raise
several questions.
Performance challenges were discussed in the role of the transport
layer.
Summary: DoD intends to implement the RFC 4594 service classes in the
GIG, including Assured Elastic. Broad view of Assured elastic
implementation that enables the transport layer and congestion control
to play a major role. Interest in contributing to the ICCRG Problem
statement draft.

Comments from Aaron Falk. Question by Larry answered by Chris.

Session # 2:

K.K Ramakrishnan: "LT-TCP: Loss Tolerant TCP"

Goal: Extend the dynamic range of TCP into high loss regimes.
Results show that performance of LT-TCP is much better compared to that
of TCP-SACK.
Results were also given for co-channel interference
LT-TCP provides robustness even under conditions of large and burst loss
rates. Gives increased dynamic range, high good put, and avoids
timeouts.

Lachlan Andrew: "Rate control with packet corruption"

Nandita Dukkipati: Announcement of workshop at Stanford

Nandita announced a workshop at Stanford for the need of new transport
or high speed protocols.
Questions by Michael Welzl, Bob Briscoe, Ted Faber

Session # 3: Lars Eggert: "Experimental congestion control proposals and
IETF/IAB/ICCRG"

An evolved TCP needs to be a safe standard.
Question by Tim Sheppard: What if you open multiple connections?
Interest in new CC features for major TCP stacks (BIC & CUBIC in Linux
and CTCP in Windows vista)
IETF is the originator and maintainer of TCP
IETF/IRTF involvement: implementers of new CC mechanisms should bring
them to IETF/IRTF
Class-1: Document current stack behavior
Which subset of the specifications is implemented and ignored?
Future examples?
- Linux: delayed-ACK suppression during slow-start
- Vista: impact of enabling ECN, window-scaling etc.
Class-2: Experimental specifications
Goal: Mechanisms that may eventually progress onto the standards track.
Internet-drafts intended for experimental RFC

Proposed approach, Phase 1
Work split between IETF and IRTF, bring individual internet draft to
ICCRG first. ICCRG reviews draft and existing body of work. After ICCRG
consensus, send draft reviews to TSV area. If adopted, publish
experimental RFC out of the TSV area

Aaron Falk: If something is not ready for wide-scale deployment,
experimental RFC will label it, don?t use it as default. Experimental,
not Informational for documentation of (past) experiments.

Proposed approach, Phase 2
IETF is not a research organization but IRTF is. ICCRG coordinates this
effort.
Bob Briscoe: What are you trying to achieve by doing that?
Doan Hoang: a paragraph for security may be added
Ted Faber: What is the incentive for IRTF to do that? Interoperating
information?

Session # 4: Discussion: What should the ICCRG be doing?

Main points of discussion:
To review a protocol
criteria for ?safe? (?good?, e.g., performance etc)
pass/fail safety criteria as an initial step?
hard test cases vs. soft guidelines?
List of things proposers need to bring to the RG
	Initial spec & paper citations with data
	Use TMRG scenarios & metrics
RG review is iterative process
Organization of the structure and reviews
H-TCP is there, CUBIC and C-TCP coming soon
Clarify the benefit of the process to the proposer

Day-2:
Session # 1:

Tom Phelan: "DCCP, TFRC and Open Problems in congestion control for
media applications"

Discussion on defining what is ?congestion collapse? by Bob Briscoe, Tim
Shepard, Michael Welzl and Tom Phelan

(Ted Faber and) Eric Coe: "Congestion control with explicit feedback"

Doan B. Hoang: "FICC-Diffserv: using CC as a QoS element"

Bob Briscoe: "Flow rate Fairness: Dismantling a Religion"

Discussion on fairness

Final discussion: Michael Welzl: can we use the procedure from Lars
Eggert's talk for other cc. proposals too?
Tim Shepard: should ask the list, many attendees have already left the
meeting.
Lars Eggert: should not be a mandatory procedure for anything other than
high-speed-TCP proposals
Michael Welzl: so it's totally voluntarily, no need to formally agree on
anything

From: [email-masked] ([email-masked])
Date: Mon Feb 12 04:01:04 2007
Subject: [Iccrg] Re: [e2e] benchmarking new tcp congestion control algorithms
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

I red the paper and I think it is a good starting point, however other metrics
should be included.
It seems that the focus is only on the capability of the algorithms to achieve
the full link utilization (maintaining fairness) and not in the congestion
control capabilities of the proposals (the capability to avoid congestion, i.e.
not stressing a stressed networks?). 
The performance analysis should focus on the impact of new algorithms on the
network and on other flows.

**** BEGIN ADVERTISING ****
For instance in our paper presented at pfldnet07
(http://wil.cs.caltech.edu/pfldnet2007/paper/YeAH_TCP.pdf), we defined the
"Fair-to-Reno" factor as the ratio of the aggregated goodput of n Reno flows
competing against a Reno flow, to the aggregated goodput of n Reno flows
competing against the selected algorithm. This metric is good to indicate the
effect that have new algorithms on standard Reno congestion control (persistent
connections). We show that some algorithms steal a lot of bandwidth to Reno
connections also in scenarios where Reno performs well... Is this what we
expect from a new algorithm?
**** END ADVERTISING ****

But I think that this is not enough. We should also have a look on the effect of
new proposals on Web traffic (and not only the viceversa). E.g. high congestion
loss probabilities can block new web connections during the three way handshake
and provoke problems to small window flows.
In this sense, I think it is very important to look at the packet loss
probability induced by the congestion control algorithm (both packet loss
probability and number of losses per congestion event) and on the average and
standard deviation of the queue utilization.

As a second issue, to have comparable results we should converge also to define
basic TCP parameters values (I did not yet have a look to the ns-2 scripts):
- initial slow start threshold (I suggest using limited slow start).
- TCP internal buffer sizes (I suggest 2*(bandwidth-delay product + bottleneck
buffer sizes))
- etc..

As many of you have experienced, on highspeed links every single parameter can
have a strong impact on the overall result.

Francesco

Quoting Douglas Leith <[email-masked]>:

> I've put together a set of short ns scripts to carry out the tcp  
> benchmark tests described in
> 
> Experimental evaluation of high-speed congestion control protocols,  
> Li, Y.T, Leith,D., Shorten,R. Transactions on Networking, 2007 (see  
> http://www.hamilton.ie/net/eval/ToNfinal.pdf).
> 
> The ns scripts are at http://www.hamilton.ie/net/eval/tcptesting.zip.
> 
> Its now very easy to rerun these tests against proposed new  
> congestion control algorithms.  Baseline tests for standard tcp, high- 
> speed tcp, scalable tcp, bic tcp, fast tcp and htcp are reported in  
> http://www.hamilton.ie/net/eval/ToNfinal.pdf and these experimental  
> measurements can be directly compared against the simulation results  
> generated by the script.
> 
> Let me know if you have any comments.
> 
> Doug
> 

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

From: [email-masked] (Aaron Falk)
Date: Sun Feb 11 19:12:00 2007
Subject: [Iccrg] webcast & jabber room information for the ICCRG meeting
References: <[email-masked]>
Message-ID: <[email-masked]>

A webcast will be available for ICCRG meeting at the URLs below.  My  
understanding is that the video will be available for offline viewing  
as well.  Times are in US PDT.  (I haven't used the webcast services  
at ISI before and there may be hiccups.  Please be patient. :)

Also, possibly useful for questions from webcast viewers, a jabber  
room for groupchat will be available at [email-masked].   
Information on Jabber clients, accounts, and the IETF jabber server  
is available at <http://www.ietf.org/meetings/text_conf.html>.  Free  
accounts are available at <http://www.postel.org/jabber>.

--aaron

------------------------------------------

Day 1 02/12/2007

Session 1 9:00am - 10:45am:
http://webcasterms.isi.edu/mediasite/viewer/? 
peid=64846f9b-1b4c-4775-84f4-c06775e547c8

Session 2 11:00am - 1:30pm:
http://webcasterms.isi.edu/mediasite/viewer/?peid=228d290b-8196-485f- 
bb9d-ee5b1f168019

Session 3  1:45pm - 3:25pm:
http://webcasterms.isi.edu/mediasite/viewer/? 
peid=05590890-2e35-488d-81bb-66e6428b6470

Session 4  3:30pm - 6:00pm:
http://webcasterms.isi.edu/mediasite/viewer/? 
peid=95c9aff9-732f-4d3d-915c-e2df43b809a1

Day 2 02/13/2007

Session 1: 9:00am - 10:30am:
http://webcasterms.isi.edu/mediasite/viewer/?peid=4aa00350-f96f-41cd- 
b2e8-1c0b904288f1

Session 2: 10:45am - 1:00pm:
http://webcasterms.isi.edu/mediasite/viewer/?peid=bb9e7bad-3838-451d- 
bbe3-9b319d3b0ec8

From: [email-masked] (Douglas Leith)
Date: Sun Feb 11 12:33:04 2007
Subject: [Iccrg] benchmarking new tcp congestion control algorithms
References: <[email-masked]>
Message-ID: <[email-masked]>

Just posted this to the end2end list, but in view of the discussions  
at pfldnet last week and the agenda for the iccrg meeting tomorrow,  
it might be topical for iccrg.

I've put together a set of short ns scripts to carry out the tcp  
benchmark tests described in

Experimental evaluation of high-speed congestion control protocols,  
Li, Y.T, Leith,D., Shorten,R. Transactions on Networking, 2007 (see  
http://www.hamilton.ie/net/eval/ToNfinal.pdf).

The ns scripts are at http://www.hamilton.ie/net/eval/tcptesting.zip.

Its now very easy to rerun these tests against proposed new  
congestion control algorithms.  Baseline tests for standard tcp, high- 
speed tcp, scalable tcp, bic tcp, fast tcp and htcp are reported in  
http://www.hamilton.ie/net/eval/ToNfinal.pdf and these experimental  
measurements can be directly compared against the simulation results  
generated by the script.

Let me know if you have any comments.

Doug

From: [email-masked] (Francesco Vacirca)
Date: Thu Feb  1 10:46:24 2007
Subject: [Iccrg] Re: [tcpm] Separate header checksums and WiFi
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Some link layers use a strongest FEC to protect header. E.g. in some 
UMTS coding scheme the link layer employs a 1/3 codification for RLC 
header, whereas the payload can use a different scheme (e.g. from 4/5 to 
1/3)... Maybe it could be applied also to TCP. Note that this can 
decrease the goodput in case of non lossy links... obviously it depends 
on the ratio between useful bits and transmitted bits.

In the 802.11 standard some part of the packet (MAC header) is sent with 
a different rate to be more protected against channel impairments and 
also for compatibility purposes. A cross layer approach could adopt low 
rate also for TCP header (also IP obviously)... but I do not think that 
the benefits are more than disadvantages.

One more thing... in case of Michael experiments, are the packet losses 
on the channel due to SNR fluctuations or due to MAC collisions?
In the second case, it is quite normal that the whole packet 
(header+payload) is corrupted.

Francesco

Michael Welzl wrote:
> I agree, and am happy to contribute what I have!!!!!
> 
> (which is: the results, but not the time)
> 
> 
> On Wed, 2007-01-31 at 18:14, Joe Touch wrote:
>> Beyond what Ethan is suggesting, this is useful to write up more fully
>> and publish, e.g., at Globecom or ICC. Negative results, as Ethan notes,
>> are critical to the community as a whole.
>>
>> Joe
>>
>> Ethan Blanton wrote:
>>> Michael Welzl spake unto us the following wisdom:
>>>> I figured that the only convincing way to prove him
>>>> wrong is to actually do a real-life test. I did, and
>>>> proved him right  :)  that is, disabling checksums for
>>>> parts of packets doesn't yield much of a benefit in
>>>> WiFi networks, where it seems that frames are delivered
>>>> in an all-or-nothing fashion.
>>> I have to applaud this move.  All too often we only talk about the
>>> things we did that *worked*, and the same questions about things that
>>> any number of people would tell you doesn't work come up over and
>>> over.  For this particular topic, there is now a citation, so the next
>>> guy won't have to go try it himself.  Thank you.
>>>
>>> Ethan
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> tcpm mailing list
>>> [email-masked]
>>> https://www1.ietf.org/mailman/listinfo/tcpm

From: [email-masked] (Francesco Vacirca)
Date: Thu Feb  1 10:46:24 2007
Subject: [Iccrg] Re: [tcpm] Separate header checksums and WiFi
Message-ID: <[email-masked]>

below the answer from Michael:

On Thu, 2007-02-01 at 11:24, Francesco Vacirca wrote:
> Some link layers use a strongest FEC to protect header. E.g. in some 
> UMTS coding scheme the link layer employs a 1/3 codification for RLC 
> header, whereas the payload can use a different scheme (e.g. from 4/5 to 
> 1/3)... Maybe it could be applied also to TCP. Note that this can 
> decrease the goodput in case of non lossy links... obviously it depends 
> on the ratio between useful bits and transmitted bits.
> 
> In the 802.11 standard some part of the packet (MAC header) is sent with 
> a different rate to be more protected against channel impairments and 
> also for compatibility purposes. A cross layer approach could adopt low 
> rate also for TCP header (also IP obviously)... but I do not think that 
> the benefits are more than disadvantages.
> 
> One more thing... in case of Michael experiments, are the packet losses 
> on the channel due to SNR fluctuations or due to MAC collisions?
> In the second case, it is quite normal that the whole packet 
> (header+payload) is corrupted.

They are generally due to SNR fluctuations, by transmitting
between two notebooks in ad hoc mode (the only way that
disabling the CRC worked for us). I remember that Mattia
also did a quick check with one more notebook, to see if
MAC influences the result, but it didn't seem to play a role
(I don't remember if this test made it into the document in
the end... I think not).

It would be interesting to know why errors occur in the
fashion that we saw; we measured, but don't really have
an explanation. Perhaps it's the PHY coding.

Anyway, for those of you in who didn't see my previous
email and are confused, this link should explain it:
http://www.welzl.at/research/projects/corruption/index.html

Cheers,
Michael