Subject: [Iccrg] review of high-speed proposals?
From: [email-masked] (Lars Eggert)
Date: Tue Aug 31 08:23:36 2010

Hi,

Tom Narten has pointed out that some US DOD requirements are referring to CUBIC and Compound, and that it would be good to have IETF-reviewed RFCs available for them to point to.

I'd therefore like to ask again if the authors could update these documents so they can be taken on by the IETF TCPM WG?

Thanks,
Lars

On 2010-6-3, at 16:12, Eggert Lars (Nokia-NRC/Espoo) wrote:
> Thanks - you guys are organized! :-)
> 
> Authors, it seems clear that the token is with you if you want something to happen with regards to these proposals on the IETF side.
> 
> Lars
> 
> On 2010-6-3, at 16:02, Michael Welzl wrote:
> 
>> Hi!
>> 
>> 
>> On Jun 3, 2010, at 2:42 PM, Lars Eggert wrote:
>> 
>>> Hi,
>>> 
>>> I'm wondering what the status of the ICCRG reviews of the various  
>>> high-speed TCP proposals is? IIRC, these three proposals were  
>>> supposed to hit TCPM after ICCRG had reviewed them:
>>> 
>>> 	draft-rhee-tcpm-cubic
>> 
>> Several reviews were made, suggestions were given to the authors, who  
>> haven't done anything for a long time now.
>> More: http://trac.tools.ietf.org/group/irtf/trac/wiki/ICCRG_cubic
>> 
>> 
>>> 	draft-leith-tcp-htcp
>> 
>> One review was made, suggestions were given to the author, who hasn't  
>> done anything for a long time now.
>> More: http://trac.tools.ietf.org/group/irtf/trac/wiki/ICCRG_htcp
>> 
>> 
>>> 	draft-sridharan-tcpm-ctcp
>> 
>> Several reviews were made, suggestions were given to the authors, who  
>> addressed them;
>> this document was then (a long time ago) deemed ready for tossing it  
>> over to TCPM, but
>> the authors have not pursued this activity so far.
>> More: http://trac.tools.ietf.org/group/irtf/trac/wiki/ICCRG_ctcp
>> 
>> Cheers,
>> Michael
>> 
> 
> <smime.p7s><ATT00001..txt>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3815 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20100831/dad0177f/smime.bin

From: [email-masked] (Lars Eggert)
Date: Wed Aug 18 08:51:22 2010
Subject: [Iccrg] Re: [IRSG] AD review:  draft-irtf-iccrg-welzl-congestion-control-open-research-07
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

just FYI, the document can't move forward until there is an update...

Lars

On 2010-7-17, at 1:16, Michael Welzl wrote:

> Dear ICCRG,
> 
> draft-irtf-iccrg-welzl-congestion-control-open-research-07:
> http://tools.ietf.org/html/draft-irtf-iccrg-welzl-congestion-control-open-research-07
> is now in one of the last phases before RFC publication. One
> issue that needs to be addressed is:
> 
> (from Lars Eggert):
> 
>> Section 1., paragraph 1:
>>>  This document, result of the ICCRG Research Group, describes some
>>>  of the open research topics in the domain of Internet congestion
>>>  control that are known today.
>> 
>> The introduction does not adequately describe what level of consensus
>> and review this document has received in the ICCRG. See RFC5743
>> Section 2.1.
> 
> Our intention is to change this text to:
> 
> "This document represents the consensus of the ICCRG."
> 
> but I want to make sure that noone has a problem with this.
> 
> Given that this has been on our agenda for a long time now, and
> received a lot of support from the group, via emails and meetings,
> I think it's probably acceptable to go for a very short deadline here:
> If you don't agree with this consensus, please say so by
> the end of next week, i.e. before the meeting.
> 
> Thanks,
> 
> cheers,
> Michael
> 
> 
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3815 bytes
Desc: not available
Url : http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20100818/e425414b/smime.bin
>From [email-masked]  Mon Aug 30 10:56:14 2010
From: [email-masked] (Michael Welzl)
Date: Mon Aug 30 10:55:25 2010
Subject: [Iccrg] PFLDNeT and ICCRG meeting
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Dear all,

I would like to remind you of this opportunity for submitting a paper.

At the same time, I'd like to give an update on upcoming ICCRG meetings:
- we will not meet at the upcoming Beijing IETF
- we will, as announced previously and below, meet at this workshop.  
If you have something you'd like to present at this meeting, send me  
and Wes an email please, stating the title and expected duration of  
your talk.

Cheers,
Michael

On Aug 15, 2010, at 2:39 PM, Michael Welzl wrote:

> Hi all,
>
> Please consider the CFP below, definitely of interest to the group.  
> As usual we'll co-locate a meeting with this,
> this time on 29. November 2010.
>
> Cheers,
> Michael
>
>
> CALL FOR PAPERS
>
> PFLDNeT 2010
>
> The 8th International Workshop on Protocols for Future,
> Large-Scale and Diverse Network Transports (PFLDNeT)
>
> Franklin & Marshall College, Lancaster, Pennsylvania, USA
> November 28-29, 2010
> Web page: http://pfld.net/2010
>
>
> Scope:
>
> The Internet continues to evolve along several dimensions, allowing
> more and more end systems to communicate in increasingly diverse ways.
> At one end of the performance spectrum, the Internet protocols provide
> communication facilities for extremely-high-speed special-use
> networks. At the other end of the performance spectrum, the Internet
> contains very low-power and low-bandwidth networks that cater to
> infrequent, bursty communication. Enabling efficient and high-
> performance end-to-end communication across such a diverse
> internetwork is a difficult problem, which is not solved by current
> transport layer protocols.  The need to support an application base
> that grows more and more dissimilar adds additional challenges.
>
> The 8th International Workshop on Protocols for Future, Large-scale &
> Diverse Network Transports (PFLDNeT) brings together researchers and
> practitioners from all continents to exchange their ideas and
> experiences in the area of transport issues for modern communication
> networks. The workshop provides theorists, experimentalists and
> technologists with a focused, highly interactive opportunity to
> present, discuss and exchange experience on leading research,
> development and future directions in transport and application
> protocols for networks that are increasingly growing in size,
> heterogeneity and dynamicity of interaction.
>
> PFLDNeT 2010 solicits papers that further the research on end-to-end
> communication protocols for todays and tomorrows Internet in all its
> diversity along the continuum from specialized grid networks, optical
> transports, wireless connections, to lossy and low-power networks.  A
> specific focus of the workshop lies on transport protocols for the
> efficient end-to-end transfer of data for a diverse set of
> applications and application-layer protocols.
>
> Now approaching its eighth instantiation, the PFLDneT workshop has
> broadened its focus over the years from protocols targeted at specific
> fast, long-distance networks (the original expansion of the PFLDneT
> acronym) into a venue where all kinds of new ideas relating to
> end-to-end transport protocols for diverse network scenarios are being
> discussed first.
>
> The previous International Workshops on Protocols for Fast, Long-
> Distance Networks held at CERN (2003), Argonne (2004), Lyon (2005),
> Nara (2006), Marina del Rey (2007), Manchester (2008), and Tokyo
> (2009) were very successful in bringing together many researchers from
> all over the world, including North America, Europe and Asia, who are
> working on these problems.  PFLDNeT 2010 will continue this tradition,
> and provide a perfect forum for researchers in this area to exchange
> ideas and experience.
>
> As in previous years, a meeting of the IRTF Internet Congestion
> Control Research Group (ICCRG) will be co-located with PFLDNeT, on
> November 29, 2010.
>
>
> Important Dates and Relevant Event Information:
>
> Abstract submission: September 20, 2010
> Position paper submission: September 27, 2010
> Notification of acceptance: October 25, 2010
> Final camera ready submission: November 14, 2010
> Workshop: November 28-29, 2010
> IRTF ICCRG meeting (co-located): November 29, 2010
>
> Note: PFLDNeT 2010 will be immediately before CoNEXT 2010, and its  
> venue
> is located only a short drive or train ride from Philadelphia,  
> making it
> easy to attend both events in one trip.
>
>
> Topics:
>
> PFLDNeT 2010 covers all aspects related to transport protocols for the
> current and future Internet, including, but not limited to:
>
> - Transport protocol development
> - Enhancements to TCP and other transports
> - Innovative congestion control mechanisms
> - Novel data transport protocols designed for new networks and  
> applications
> - Transport services for data center networks and grids
> - Transport services for wireless and sensor networks
> - Explicit signaling protocols: optimization criteria and deployment  
> strategies
> - Pacing and shaping of traffic
> - Parallel transfers and multi-streaming
> - Performance evaluation
> - Modeling and simulation-based results
> - Interaction of transport protocols and network equipment
> - Experiments on real networks and live measurements
> - Transport protocol benchmarking
> - Transport over optical networks
> - Transport implementation and hardware issues
> - End system performance
> - Data replication and striping
> - Applications with demanding or unusual network performance  
> requirements
> - Bulk-data transfer applications
> - Quality-of-service and scalability issues
> - Multicast
>
>
> Workshop Organizers:
>
> Program Committee Chairs:
> Bryan Ford, Yale University, USA
> Injong Rhee, North Carolina State University, USA
>
> Steering Committee:
> Lachlan Andrew, Swinburne University of Technology, Australia
> Lars Eggert, Nokia Research Center, Finland
> Richard Hughes-Jones, Univ. of Manchester, UK
> Katsushi Kobayashi, AIST, Japan
> Doug Leith, Hamilton Institute, Ireland
> Injong Rhee, North Carolina State University, USA
> Pascale Vicat-Blanc, INRIA, France
> Michael Welzl, University of Oslo, Norway
>
> Technical Program Committee (preliminary):
> Scott Brim, Cisco, USA
> Dirceu Cavendish, Kyushu Institute of Technology, Japan
> Stuart Cheshire, Apple, USA
> Larry Dunn, University of Minnesota, USA
> Lars Eggert, Nokia Research Center, Finland
> Ted Faber, USC/ISI, USA
> Saikat Guha, Microsoft Research, India
> Sangtae Ha, Princeton University, USA
> Janardhan Iyengar, Franklin & Marshall College, USA
> Katsushi Kobayashi, AIST, Japan
> Aleksandar Kuzmanovic, Northwestern University, USA
> Preethi Natarajan, Cisco, USA
> Narasimha Reddy, Texas A&M University, USA
> Medy Sanadidi, UCLA, USA
> Pasi Sarolahti, Nokia Research Center, Finland
> Michael Scharf, Alcatel-Lucent, Germany
> Hideyuki Shimonishi, NEC, Japan
> Murari Sridharan, Microsoft, USA
> Joe Touch, USC/ISI, USA
> Michael Welzl, University of Oslo, Norway
> Lisong Xu, University of Nebraska, USA
>
> Local Arrangements:
> Janardhan Iyengar, Franklin & Marshall College, USA
>
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Michael Welzl)
Date: Sun Aug 15 13:36:11 2010
Subject: [Iccrg] PFLDNeT and ICCRG meeting
Message-ID: <[email-masked]>

Hi all,

Please consider the CFP below, definitely of interest to the group. As  
usual we'll co-locate a meeting with this,
this time on 29. November 2010.

Cheers,
Michael

CALL FOR PAPERS

PFLDNeT 2010

The 8th International Workshop on Protocols for Future,
Large-Scale and Diverse Network Transports (PFLDNeT)

Franklin & Marshall College, Lancaster, Pennsylvania, USA
November 28-29, 2010
Web page: http://pfld.net/2010

Scope:

The Internet continues to evolve along several dimensions, allowing
more and more end systems to communicate in increasingly diverse ways.
At one end of the performance spectrum, the Internet protocols provide
communication facilities for extremely-high-speed special-use
networks. At the other end of the performance spectrum, the Internet
contains very low-power and low-bandwidth networks that cater to
infrequent, bursty communication. Enabling efficient and high-
performance end-to-end communication across such a diverse
internetwork is a difficult problem, which is not solved by current
transport layer protocols.  The need to support an application base
that grows more and more dissimilar adds additional challenges.

The 8th International Workshop on Protocols for Future, Large-scale &
Diverse Network Transports (PFLDNeT) brings together researchers and
practitioners from all continents to exchange their ideas and
experiences in the area of transport issues for modern communication
networks. The workshop provides theorists, experimentalists and
technologists with a focused, highly interactive opportunity to
present, discuss and exchange experience on leading research,
development and future directions in transport and application
protocols for networks that are increasingly growing in size,
heterogeneity and dynamicity of interaction.

PFLDNeT 2010 solicits papers that further the research on end-to-end
communication protocols for todays and tomorrows Internet in all its
diversity along the continuum from specialized grid networks, optical
transports, wireless connections, to lossy and low-power networks.  A
specific focus of the workshop lies on transport protocols for the
efficient end-to-end transfer of data for a diverse set of
applications and application-layer protocols.

Now approaching its eighth instantiation, the PFLDneT workshop has
broadened its focus over the years from protocols targeted at specific
fast, long-distance networks (the original expansion of the PFLDneT
acronym) into a venue where all kinds of new ideas relating to
end-to-end transport protocols for diverse network scenarios are being
discussed first.

The previous International Workshops on Protocols for Fast, Long-
Distance Networks held at CERN (2003), Argonne (2004), Lyon (2005),
Nara (2006), Marina del Rey (2007), Manchester (2008), and Tokyo
(2009) were very successful in bringing together many researchers from
all over the world, including North America, Europe and Asia, who are
working on these problems.  PFLDNeT 2010 will continue this tradition,
and provide a perfect forum for researchers in this area to exchange
ideas and experience.

As in previous years, a meeting of the IRTF Internet Congestion
Control Research Group (ICCRG) will be co-located with PFLDNeT, on
November 29, 2010.

Important Dates and Relevant Event Information:

Abstract submission: September 20, 2010
Position paper submission: September 27, 2010
Notification of acceptance: October 25, 2010
Final camera ready submission: November 14, 2010
Workshop: November 28-29, 2010
IRTF ICCRG meeting (co-located): November 29, 2010

Note: PFLDNeT 2010 will be immediately before CoNEXT 2010, and its venue
is located only a short drive or train ride from Philadelphia, making it
easy to attend both events in one trip.

Topics:

PFLDNeT 2010 covers all aspects related to transport protocols for the
current and future Internet, including, but not limited to:

- Transport protocol development
- Enhancements to TCP and other transports
- Innovative congestion control mechanisms
- Novel data transport protocols designed for new networks and  
applications
- Transport services for data center networks and grids
- Transport services for wireless and sensor networks
- Explicit signaling protocols: optimization criteria and deployment  
strategies
- Pacing and shaping of traffic
- Parallel transfers and multi-streaming
- Performance evaluation
- Modeling and simulation-based results
- Interaction of transport protocols and network equipment
- Experiments on real networks and live measurements
- Transport protocol benchmarking
- Transport over optical networks
- Transport implementation and hardware issues
- End system performance
- Data replication and striping
- Applications with demanding or unusual network performance  
requirements
- Bulk-data transfer applications
- Quality-of-service and scalability issues
- Multicast

Workshop Organizers:

Program Committee Chairs:
Bryan Ford, Yale University, USA
Injong Rhee, North Carolina State University, USA

Steering Committee:
Lachlan Andrew, Swinburne University of Technology, Australia
Lars Eggert, Nokia Research Center, Finland
Richard Hughes-Jones, Univ. of Manchester, UK
Katsushi Kobayashi, AIST, Japan
Doug Leith, Hamilton Institute, Ireland
Injong Rhee, North Carolina State University, USA
Pascale Vicat-Blanc, INRIA, France
Michael Welzl, University of Oslo, Norway

Technical Program Committee (preliminary):
Scott Brim, Cisco, USA
Dirceu Cavendish, Kyushu Institute of Technology, Japan
Stuart Cheshire, Apple, USA
Larry Dunn, University of Minnesota, USA
Lars Eggert, Nokia Research Center, Finland
Ted Faber, USC/ISI, USA
Saikat Guha, Microsoft Research, India
Sangtae Ha, Princeton University, USA
Janardhan Iyengar, Franklin & Marshall College, USA
Katsushi Kobayashi, AIST, Japan
Aleksandar Kuzmanovic, Northwestern University, USA
Preethi Natarajan, Cisco, USA
Narasimha Reddy, Texas A&M University, USA
Medy Sanadidi, UCLA, USA
Pasi Sarolahti, Nokia Research Center, Finland
Michael Scharf, Alcatel-Lucent, Germany
Hideyuki Shimonishi, NEC, Japan
Murari Sridharan, Microsoft, USA
Joe Touch, USC/ISI, USA
Michael Welzl, University of Oslo, Norway
Lisong Xu, University of Nebraska, USA

Local Arrangements:
Janardhan Iyengar, Franklin & Marshall College, USA

From: [email-masked] (Mikael Abrahamsson)
Date: Thu Aug 12 07:55:07 2010
Subject: [Iccrg] IETF plenary: fast timescales
In-Reply-To: <[email-masked]>
References: <[email-masked]><[email-masked]><[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 11 Aug 2010, Woundy, Richard wrote:

> It was the manner in which Comcast reacted to those congestion events
> (resets of P2P session) that needed to change.

Yes. My opinion is that it's ok for an ISP to drop and/or delay packets, 
and change/reset DSCP values. Spoofing packets or otherwise change content 
of packets on the customers behalf is something that should require the 
customers' express wish and acceptance of this behaviour (WAN acceleration 
for instance).

> We've described a similar system which is deployed in Comcast today; see
> <https://datatracker.ietf.org/doc/draft-livingood-woundy-congestion-mgmt
> />, especially section 7.

While I on principle disagree with these kinds of systems, I can accept 
them as a stop-gap measure until more capacity can be added. I think the 
new system (detecting high users and re-marking their traffic so they get 
a lower share of the total traffic on the CMTS segment) is a sound one.

> But the core issue (with respect to the conversation about Conex) is in
> how you define "heavy users". Is it by volume of recent traffic? If
> someone sends a large volume of traffic into the network, but doesn't
> cause congestion, should they be penalized? The Conex premise is to
> identify "heavy users" by their contribution to congestion, not by their
> volume of traffic.

It's my opinion that this kind of system needs to be transparent (the user 
knows and understands what's going on) and non-discriminating, and should 
also give the best user experience possible under congestion.

For instance, on my own home connection I guarantee 25% of capacity to 
packets that are less than 200 bytes in size (mainly to make sure my 
ACKs/VoIP and ssh packets get thru), 25% to TCP/UDP packets destined or 
sourced from a few ports (typically dns/ssh etc) and then I fair-queue the 
rest. This works well and gives me extremely low latency for interactive 
applications even though I have several TCP sessions running that fill up 
the link completely. Fair-queue is a feature present in Cisco cpu based 
platforms and keeps a kind of state for TCP flows so this doesn't really 
scale, but it's also not really needed, the packet size/L4 information is 
quite enough to give good interactive performance.

On the topic of who is a "heavy user" that's a good question and not 
something that can be universally answered in a single way. My opinion is 
that you're on the right track where you're looking at who is contributing 
to congestion right now and not historically, and that one should mainly 
aim at stopping prolonged congestion to low users (subsecond congestion 
doesn't hurt as much interactively), so identifying people who sent a lot 
of traffic during the past 5 minutes and identifying that congestion 
occurred, then if prolonged congestion is likely to be happening again in 
the next 5 minutes lower the priority of the high user traffic so they get 
lower priority on access to the shared access bandwidth. If per-packet 
differentiation can be done, the TCP file transfer sessions of the heavy 
users might not even affect their interactive sessions (especially if 
they're going in the other direction of the big data packets).

Another topic:

One recommendation from this group should also be that CPE (for instance 
ADSL2+ routers) manufacturers are able to do intelligent queuing in the 
upstream direction of their devices. I don't know how many times people 
have complained that they can't get any decent download speed while they 
are uploading. Their speed is limited by their ACKs being stuck 1-2 
seconds in the FIFO outgoing buffer going upstream. Even really simple 
queuing as I described above would really improve interactive performance.

-- 
Mikael Abrahamsson    email: [email-masked]

From: [email-masked] (Woundy, Richard)
Date: Wed Aug 11 19:36:54 2010
Subject: [Iccrg] IETF plenary: fast timescales
In-Reply-To: <[email-masked]>
References: <[email-masked]><[email-masked]><[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

> Ok, you were overselling the cable tv access layer. The reasoning
still stands.

Actually, edge congestion was fairly uncommon, so I would disagree with
your characterization.

It was the manner in which Comcast reacted to those congestion events
(resets of P2P session) that needed to change.

Moving from the topic of Comcast to more general discussion, let me
discuss your original points:

> Also, the best and easiest way (which is also net neutral) to solve
congestion is to make sure that the heavy users either mark their
packets as low priority (or it can be marked for them by means of having
a different type of subscription) and queue accordingly

We've described a similar system which is deployed in Comcast today; see
<https://datatracker.ietf.org/doc/draft-livingood-woundy-congestion-mgmt
/>, especially section 7.

But the core issue (with respect to the conversation about Conex) is in
how you define "heavy users". Is it by volume of recent traffic? If
someone sends a large volume of traffic into the network, but doesn't
cause congestion, should they be penalized? The Conex premise is to
identify "heavy users" by their contribution to congestion, not by their
volume of traffic.

> Congestion is rare because bad performance is not tolerated by the end
users and they switch providers.

Keeping congestion rare is my goal too.

-- Rich

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: Wednesday, August 11, 2010 1:40 PM
To: Woundy, Richard
Cc: [email-masked]; [email-masked]
Subject: RE: [Iccrg] IETF plenary: fast timescales

On Wed, 11 Aug 2010, Woundy, Richard wrote:

> Thanks for the (fake) sympathy. Comcast wasn't congesting its core -- 
> but hey, believe what you want.

Ok, you were overselling the cable tv access layer. The reasoning still 
stands.

-- 
Mikael Abrahamsson    email: [email-masked]

From: [email-masked] (Mikael Abrahamsson)
Date: Wed Aug 11 18:37:52 2010
Subject: [Iccrg] IETF plenary: fast timescales
In-Reply-To: <[email-masked]>
References: <[email-masked]><[email-masked]><[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 11 Aug 2010, Woundy, Richard wrote:

> Thanks for the (fake) sympathy. Comcast wasn't congesting its core -- 
> but hey, believe what you want.

Ok, you were overselling the cable tv access layer. The reasoning still 
stands.

-- 
Mikael Abrahamsson    email: [email-masked]

From: [email-masked] (Tony Li)
Date: Wed Aug 11 17:59:33 2010
Subject: [Iccrg] IETF plenary: fast timescales
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Aug 11, 2010, at 5:28 AM, ken carlberg wrote:

> and speaking of which, one tool you didn't mention is MPLS (aka, traffic engineering).  This is done in part because one can't over-provision to satisfy the sum capacity of all leaf links.  Up until about a year ago, this was becoming more acute with ever rising P2P traffic, motivating the recent actions from Comcast.  

Ken,

The effect of P2P within Comcast was to create point sources and sinks with effectively infinite capacity.  You can't provision to support these at all.  The correct approach is per-user queuing at the leaf.  

The point of MPLS/TE is that routing only gives large knobs and circuits only come in quantized units, so the ability to direct traffic around paths that are non-shortest paths allows an ISP to avoid localized hot spots.

Regards,
Tony

From: [email-masked] (Woundy, Richard)
Date: Wed Aug 11 17:04:51 2010
Subject: [Iccrg] IETF plenary: fast timescales
In-Reply-To: <[email-masked]>
References: <[email-masked]><[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

>>  Up until about a year ago, this was becoming more acute with ever 
>> rising P2P traffic, motivating the recent actions from Comcast.

> Poor comcast. Err.. no, the other way around, poor users who actually
try
> to use the bw comcast promised them. Again, if you're congesting the
core

Thanks for the (fake) sympathy. Comcast wasn't congesting its core --
but hey, believe what you want.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Mikael Abrahamsson
Sent: Wednesday, August 11, 2010 11:32 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Iccrg] IETF plenary: fast timescales

On Wed, 11 Aug 2010, ken carlberg wrote:

> lucky you.  try spending time in South America, where economics still 
> puts a significant downward pressure on traffic between tiered
providers 
> egressing a country/region.  Or, try other spots along the pacific
rim. 
> Point being that the entire Internet doesn't have the luxury of 
> significant over provisioning -- which was the point of one of the 
> speakers.

You don't need to significantly overprovision, you need to assure that
at 
whatever bw/pricepoint you choose, you can afford to upgrade the network

if the customers actually use the bandwidth they buy. If you can't,
you're 
doing it wrong. Don't blame the users for actually using the access 
bandwidth you're giving them.

If you don't want them to use bw for prolonged periods of time, use 
CIR/PIR in your policer and allow 30 second bursts, then police it to
the 
lower level where you're not congesting your core.

Again, ISPs who congest their core are cheating their users.

> and speaking of which, one tool you didn't mention is MPLS (aka,
traffic 
> engineering).  This is done in part because one can't over-provision
to 
> satisfy the sum capacity of all leaf links.

You don't need to, you just need to provision enough so that the 
statistical probability of congestion is extremely low. Congesting for 
hours on end every day is not a "oops, something went wrong"-event, it's

cheating the customers.

>  Up until about a year ago, this was becoming more acute with ever 
> rising P2P traffic, motivating the recent actions from Comcast.

Poor comcast. Err.. no, the other way around, poor users who actually
try 
to use the bw comcast promised them. Again, if you're congesting the
core 
you've sold more to your customers than you can handle, so you either
need 
to upgrade or lower the speed per user. This of course would mean not 
being competitive in the market, so instead of doing the right thing,
they 
chose to skimp on the bw actually delivered.

> you make some good points, and I would agree that barring the back-hoe

> problem (or other disasters that damage infrastructure), one should 
> mostly see congestion closer towards the customer access links.  But I

> would just contend that the picture you paint isn't complete.

It's not complete for some people, but I contend that these people are 
trying to sell high and deliver low, and that's not ok. Their customers 
need to be able to see what's going on, we shouldn't let them get away 
with it.

-- 
Mikael Abrahamsson    email: [email-masked]

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

From: [email-masked] (Mikael Abrahamsson)
Date: Wed Aug 11 16:28:36 2010
Subject: [Iccrg] IETF plenary: fast timescales
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 11 Aug 2010, ken carlberg wrote:

> lucky you.  try spending time in South America, where economics still 
> puts a significant downward pressure on traffic between tiered providers 
> egressing a country/region.  Or, try other spots along the pacific rim. 
> Point being that the entire Internet doesn't have the luxury of 
> significant over provisioning -- which was the point of one of the 
> speakers.

You don't need to significantly overprovision, you need to assure that at 
whatever bw/pricepoint you choose, you can afford to upgrade the network 
if the customers actually use the bandwidth they buy. If you can't, you're 
doing it wrong. Don't blame the users for actually using the access 
bandwidth you're giving them.

If you don't want them to use bw for prolonged periods of time, use 
CIR/PIR in your policer and allow 30 second bursts, then police it to the 
lower level where you're not congesting your core.

Again, ISPs who congest their core are cheating their users.

> and speaking of which, one tool you didn't mention is MPLS (aka, traffic 
> engineering).  This is done in part because one can't over-provision to 
> satisfy the sum capacity of all leaf links.

You don't need to, you just need to provision enough so that the 
statistical probability of congestion is extremely low. Congesting for 
hours on end every day is not a "oops, something went wrong"-event, it's 
cheating the customers.

>  Up until about a year ago, this was becoming more acute with ever 
> rising P2P traffic, motivating the recent actions from Comcast.

Poor comcast. Err.. no, the other way around, poor users who actually try 
to use the bw comcast promised them. Again, if you're congesting the core 
you've sold more to your customers than you can handle, so you either need 
to upgrade or lower the speed per user. This of course would mean not 
being competitive in the market, so instead of doing the right thing, they 
chose to skimp on the bw actually delivered.

> you make some good points, and I would agree that barring the back-hoe 
> problem (or other disasters that damage infrastructure), one should 
> mostly see congestion closer towards the customer access links.  But I 
> would just contend that the picture you paint isn't complete.

It's not complete for some people, but I contend that these people are 
trying to sell high and deliver low, and that's not ok. Their customers 
need to be able to see what's going on, we shouldn't let them get away 
with it.

-- 
Mikael Abrahamsson    email: [email-masked]

From: [email-masked] (ken carlberg)
Date: Wed Aug 11 13:25:53 2010
Subject: [Iccrg] IETF plenary: fast timescales
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Mikael,

> Devices are getting less and less buffers over time, not more. (re-)ECN relies on big buffers and WRED to signal congestion. Implementation of ECN (a 2001 standard) in major vendor core routers today is minimal (where the buffers are), I haven't seen it at all on switches that does policing only (and it makes little sense on a device with 1-5 ms of buffers).

yes, I'd quite agree about the sparse ECN deployment, and I wouldn't expect that to change drastically.  But the point that you're missing is that ECN support is not needed or even expected throughout the Internet.  Ideally, ECN would be placed in places that can be prone to wide variations of traffic and/or in those transits that choose to add additional notification.

> Also, the best and easiest way (which is also net neutral) to solve congestion is to make sure that the heavy users either mark their packets as low priority (or it can be marked for them by means of having a different type of subscription) and queue accordingly, or by means of monthly caps (and having the user pay for extra credits which means congested links are financed).

marking packets can be nice (and i assume you refer to diff-serv), but they only have local significance within that domain.  without a chain of trust, the code points will either be cleared, ignored, or reset to other values (eg, protecting routing traffic between adjacent BGP speakers).  

<snip>

> I'm from a market where 10/100 megabit/s ETTH is common (15-20 percent of the households have access to this service). Congestion is rare because bad performance is not tolerated by the end users and they switch providers. There are plenty of tools available to test bandwidth, and they work. People are not satisfied with badly performing ISPs so this is a problem of the past (it was "solved" 5-8 years ago).

lucky you.  try spending time in South America, where economics still puts a significant downward pressure on traffic between tiered providers egressing a country/region.  Or, try other spots along the pacific rim.  Point being that the entire Internet doesn't have the luxury of significant over provisioning -- which was the point of one of the speakers.

and speaking of which, one tool you didn't mention is MPLS (aka, traffic engineering).  This is done in part because one can't over-provision to satisfy the sum capacity of all leaf links.  Up until about a year ago, this was becoming more acute with ever rising P2P traffic, motivating the recent actions from Comcast.  

> We have plenty of tools in the toolbox already, we have precedence/dscp markings, we have ECN and there has been plenty of mechanisms proposed the past 10 years, but what is still most in use is simple WFQ and WRED, all of these are at least 10 years old but they work.

although, somewhat static.  folks don't alter those settings with any great frequency.

> We should work to remove congestion, not hide its impact. Congestion within the ISP means something is full and the ISP hasn't provisioned enough bandwidth to deliver the service it promised to the user. The only place congestion should happen is on customer access links.

you make some good points, and I would agree that barring the back-hoe problem (or other disasters that damage infrastructure), one should mostly see congestion closer towards the customer access links.  But I would just contend that the picture you paint isn't complete.

cheers,

-ken

From: [email-masked] (Mikael Abrahamsson)
Date: Wed Aug 11 10:54:09 2010
Subject: [Iccrg] IETF plenary: fast timescales
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On Wed, 11 Aug 2010, Frank Kelly wrote:

> The above discussion is concerned with signalling congestion,
> and how fast end-systems can react, if they want to. How to align incentives 
> with congestion signals is of course the tricky issue that Bob is working on 
> - http://bobbriscoe.net/projects/refb/

To re-iterate what I said in Stockholm:

Devices are getting less and less buffers over time, not more. (re-)ECN 
relies on big buffers and WRED to signal congestion. Implementation of ECN 
(a 2001 standard) in major vendor core routers today is minimal (where the 
buffers are), I haven't seen it at all on switches that does policing 
only (and it makes little sense on a device with 1-5 ms of buffers).

Also, the best and easiest way (which is also net neutral) to solve 
congestion is to make sure that the heavy users either mark their packets 
as low priority (or it can be marked for them by means of having a 
different type of subscription) and queue accordingly, or by means of 
monthly caps (and having the user pay for extra credits which means 
congested links are financed).

If a core link (not the individual user access link) is congested, then 
the ISP is not doing its job. The real problem is to visualise this to the 
customer so they know and can switch providers. If they can't switch 
providers then this is a political problem and not something we can solve 
by technical means.

I'm from a market where 10/100 megabit/s ETTH is common (15-20 percent of 
the households have access to this service). Congestion is rare because 
bad performance is not tolerated by the end users and they switch 
providers. There are plenty of tools available to test bandwidth, and they 
work. People are not satisfied with badly performing ISPs so this is a 
problem of the past (it was "solved" 5-8 years ago).

So, my guess is that (re-)ECN, feedback, all of this, will get very 
limited usage on the actual Internet. I don't oppose the effort put into 
it, but I think it's misdirected. Time and effort would be better spent 
actually making it easier for the end user to see that congestion is going 
on, and act accordingly. This involves showing the classical congestion 
signals; variance in RTT and packet loss.

We have plenty of tools in the toolbox already, we have precedence/dscp 
markings, we have ECN and there has been plenty of mechanisms proposed the 
past 10 years, but what is still most in use is simple WFQ and WRED, all 
of these are at least 10 years old but they work.

We should work to remove congestion, not hide its impact. Congestion 
within the ISP means something is full and the ISP hasn't provisioned 
enough bandwidth to deliver the service it promised to the user. The only 
place congestion should happen is on customer access links.

-- 
Mikael Abrahamsson    email: [email-masked]

From: [email-masked] (Frank Kelly)
Date: Wed Aug 11 09:27:05 2010
Subject: [Iccrg] IETF plenary: fast timescales
Message-ID: <[email-masked]>

Hi Joel

You asked a great question about time-scales at the IETF Thursday plenary.

I didn't understand the question at the time, but Bob Briscoe did.

Here are my thoughts on the question, as I now understand it.

Imagine a queue where packets are marked if the queue
length is above a threshold and not otherwise,
and imagine that end-systems react to congestion
information much like TCP: they slow down if acknowledgements
show that packets were marked and speed up otherwise.

If the RTT of a flow is long compared with the relaxation time of the queue, 
then the flow's instantaneous sending rate will not be highly correlated with 
the instantaneous queue size, but the average sending rate over periods long 
compared with the RTT will be heavily influenced by the proportion of
packets marked. If this proportion is high, then the flow is slow and the
total number of marks collected for a fixed size file transfer is high.

If the RTT of a flow is short compared with the
relaxation time of the queue, then the flow's
nstantaneous sending rate will be correlated with
the instantaneous queue size: fewer packets will
be sent when the queue size is above the threshold.
In this case the flow has a short enough RTT to be able to take advantage of 
queueing transients.

If I understood your point, it was that queue size fluctuations are becoming 
faster and faster, as a consequence of faster routers. I agree!
See, e.g., http://www.statslab.cam.ac.uk/~frank/smi.html

The above discussion is concerned with signalling congestion,
and how fast end-systems can react, if they want to. How to align incentives 
with congestion signals is of course the tricky issue that Bob is working on - 
http://bobbriscoe.net/projects/refb/

Regards,
Frank Kelly

From: [email-masked] (Lawrence Stewart)
Date: Wed Aug 11 03:12:05 2010
Subject: [Iccrg] Meeting minutes
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

On 08/04/10 18:01, Michael Welzl wrote:
> Hi all,
> 
> Please see the minutes taken by Andrew McGregor below, and send me any
> corrections that
> you may have within the next week or so.
> 
> Thanks!
> 
> Cheers,
> Michael
> 
> 
> =========================================================

[snip]

> Title: "News from CAIA's newtcp project -- delay-based TCP and improved
> instrumentation of FreeBSD's TCP stack"
> Presenter: Michael Welzl (on behalf of CAIA)
> Time: 10 minutes
> 
> Fred Baker: the Cisco funding was me.  Reason is really the LEDBAT
> question: how do I move a whole lot of data through the network without
> destroying the ISP.  Secondly, using high-loss radios in things like
> 6lowpan, COAP where loss-based TCP really has a problem.  Idea is to
> tune to the mean instead of the congestion decay cliff, so we can get

I'm pretty sure Fred meant "tune to the knee of the congestion delay
cliff" instead of "mean" and "decay" as recorded above.

[snip]

Cheers,
Lawrence

From: [email-masked] (Jerry Chu)
Date: Tue Aug 10 17:51:26 2010
Subject: [Iccrg] Meeting minutes
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <AANLkTi=6GTs-NOCJQRp2JitOUMK=[email-masked]>

A question was raised (by someone from Nokia I think) during the
"Seeding TCP retransmission timer using SYN/SYNACK RTT sample"
presentation on the impact of the IW=10 proposal on the RTO calculation.

My answer was that according to RFC2988, the retransmission timer will
be restarted after each ack that acknowledges new data. Hence the RTO
only needs to cover 2 pkts plus the possible effect of delayed acks, but
not the whole window. A follow-up question was asked on the impact of
those stacks that only take one RTT sample per window. After some
thought I realized the frequency of the RTT sampling does not directly
affect the validity of the RTO calculation proposed here. It's the frequency
of the acks that matters. Hope this answers the question.

Best,

Jerry

On Wed, Aug 4, 2010 at 1:01 AM, Michael Welzl <[email-masked]> wrote:
>
> Hi all,
>
> Please see the minutes taken by Andrew McGregor below, and send me any corrections that
> you may have within the next week or so.
>
> Thanks!
>
> Cheers,
> Michael
>
>
> =========================================================
>
>
> Agenda (12 July 2010) of ICCRG meeting @ IETF 78
> Friday 30 July 2010, 9:00-11:30 in 0.2 Berlin
>
>
> Title: RG Status
> Presenter: Chairs
> Time: 10 minutes
>
> Title: "MulTFRC update (draft-irtf-iccrg-multfrc-00.txt)"
> Presenter: Michael Welzl
> Time: 10 minutes
>
> (no comments)
>
> Title: "News from CAIA's newtcp project -- delay-based TCP and improved
> instrumentation of FreeBSD's TCP stack"
> Presenter: Michael Welzl (on behalf of CAIA)
> Time: 10 minutes
>
> Fred Baker: the Cisco funding was me. ?Reason is really the LEDBAT question: how do I move a whole lot of data through the network without destroying the ISP. ?Secondly, using high-loss radios in things like 6lowpan, COAP where loss-based TCP really has a problem. ?Idea is to tune to the mean instead of the congestion decay cliff, so we can get fair sharing without attacking the network. ?Therefore I'm very interested in congestion control that achieves this. ?I asked one of the Contiki authors what their CC is, and reply was there is only one buffer and therefore there cannot be congestion.
>
> Lars -> lawrence: please tell me you are leaving the default in BSD at NewReno
>
> Lawrence Stewart -> Lars: Absolutely
>
> Title: "TCP modifications to reduce thin-stream latency"
> Presenter: Andreas Petlund
> Time: 20 minutes
>
> q: Do you have measurements on extra transmissions?
>
> a: Answer is in the slides: about 6 to 10 %
>
> q: Thin streams are <4 packets in flight, so all streams are thin at the beginning?
>
> a: Yes
>
> q: Bundling... when you send the second packet, how many bytes do you have in flight?
>
> a: We're not tracking that
>
> q: What about the congestion window?
>
> a: That neither, which is work to be done.
>
> Gorry: We're interested in streams that vary between thick and thin, so let's talk later.
>
> Title: "Seeding TCP retransmission timer using SYN/SYNACK RTT sample ?(draft-ycheng-tcpm-rtosynrtt-00.txt)"
> Presenter: Yu-chung Cheng
> Time: 15 minutes
>
> Gorry: Analysis is on fixed lines rather than wireless?
>
> a: Usually on those links the SYN RTT is higher, but could be lower.
>
> q: The SYN RTT on wireless can in fact be much higher, but it seems the estimator could be too high based on this.
>
> a: We could clamp to 3s.
>
> q: You have this 'd' in your formula representing delay for two packets, should you change this if the IW is 10 packets?
>
> a: TCP typically acks every other packet, so the first ack is usually after receiving two packets.
>
> q: 2988 says reset the timer after each ack, but stack may sample only per window. ?What are the implications?
>
> Title: "Scaling IW with Internet scale"
> Presenter: Matt Mathis
> Time: 10 minutes
>
> Fred Baker: How do you expect clients to know the link buffer space?
>
> A: They do in some cases.
>
> Bob Briscoe: 83 SYNs for multiple objects?
>
> A: I didn't dig through, but there were 83 SYNs
>
> Bob: Parallel for the same object?
>
> Tim: 83 immediately?
>
> Matt: I didn't check how many were cascaded.
>
> Carsten: I usually see 30-40 objects in 3-5 waves, later waves delayed by download of earlier.
>
> Matt: I've spoken to these developers (both browser and site developers) and they do it for latency... deliberately.
>
> Costin: A lot of these connections are there for pipelining your local link...
>
> Matt: Which is why it is reasonable to have some parallelism, but not that much.
>
> Aaron: What's a 'slow' link?
>
> Matt: Coming to that
>
> Bob: Problem here is, buffer size is getting smaller, based on long flows.
>
> Matt: Those analyses are for highly aggregated links, though.
>
> Bob: That analysis across both small and large numbers of flows is supposed to decrease for faster links, but to optimise startup you need more buffer.
>
> Slow links are mostly NOT SHARED, and have only a couple of segments worth of buffer. ?IW=3 is too big then.
>
> Aaron: You're saying that there is only dumb queueing?
>
> Matt: I'd hope not, but the paper I read did not say.
>
> Content developers go to a lot of trouble to spread assets across servers.
>
> Bob: Isn't that the same however you have multiple IWs at the same time.
>
> Title: "A Simulation Study on Increasing TCP's IW - Preliminary Results"
> Presenter: Ilpo Jaervinen
> Time: 30 minutes
>
> Bob: This is a useful presentation to give some intuition as to what happens. ?What sort of queues were you using?
>
> A: Tail drop
>
> Bob: I think the results would be very different with a different kind of queue.
>
> Jana: Do you have an insight as to why the fairness between bursts goes down at IW=10?
>
> Richard: What kind of stack and congestion control?
>
> A: This is ns-2, its defaults.
>
> Title: "Increasing TCP's Initial Window ?(draft-hkchu-tcpm-initcwn-01.txt)"
> Presenter: Nandita Dukkipati
> Time: 45 minutes
>
> Fred: What was the impact on sessions competing with yours? ?In other words, have you completely blasted the rest of the world off the network?
>
> A: We can't completely answer that.
>
> --- new speaker
>
> Jana: TCP latency is transfer completion time?
>
> A: Latency is time from first byte leaving to last byte acked
>
> Costin: Why is there a dip at 60kb?
>
> A: There are always some proxies, and there was a particular site skewing the data.
>
> Richard S: You're investigating long links, high RTT, what happens if you run at very short RTT?
>
> A: We also studied that, but didn't really see anything interesting.
>
> Q: Did you see initial timeouts increase?
>
> A: Somewhat, there is a slide on that.
>
> Q: Are you using a linux stack?
>
> A: Stock linux stack
>
> Q: That stack is unique in retransmission recovery.
>
> A: We're using a stock stack.
>
> Q: That should be noted.
>
> Bob: It would be better to come with the question 'what should IW be?'
>
> Nandita: Should we be trying to find a global for the internet?
>
> Lars: This is a TCPM proposal. ?We'd like to come with a proposal for standardising.
>
> Nandita: It's a great research question.
>
> Jana: Thanks for doing all this. ?I suggest that 'offered load' is too coarse a metric, we can talk about ways of doing something more realistic.
>
> Nandita: For sure... offered load >1 is unstable. ?Do you have any real traces?
>
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Michael Welzl)
Date: Wed Aug  4 16:31:23 2010
Subject: [Iccrg] MulTFRC update: draft-irtf-iccrg-multfrc-01
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi!

Thanks a lot for your extremely useful comments!

Note to the list:
I think it's safe to interpret this as another review recommending to  
proceeding with the mechanism (provided that these
rather minor issues are addressed, which should be easy enough, we  
will do that of course).

Cheers,
Michael

On Aug 4, 2010, at 3:04 PM, Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE  
CORP] wrote:

> Here are some comments I had; none are very serious or really  
> protocol-related, but are mostly just things that I thought would  
> strengthen the document as an RFC.
>
>
> Section 1
> =========
>
> - "not all data transfers are of equal importance to a user"; this  
> would be more accurate as "the required delivery rates and times for  
> all transfers are not all equal"
>
> - between the first and second paragraphs, there's a sentence or so  
> missing to indicate why using multiple actual flows is less  
> desirable than a single transport flow that can emulate the  
> congestion response of multiple actual flows.  To some extent this  
> is in the 3rd paragraph, but it would make more sense to fully  
> introduce the problem prior to the solution :).
>
> - paragraph 4: "steady-state throughput of TCP" might better be  
> "steady-state throughput of a TCP connection under the observed loss  
> rate, RTT, and segment size.
>
> - paragraph 4: "TFRC code" -> "TFRC pseudocode"
>
>
>
> Section 2
> =========
>
> - section 2.1 has inconsistent spacing in the block of one-line  
> assignments; to me, the "a = ..." form is more legible than the  
> "af=..." form, and there's plenty of horizontal room in those lines.
>
> - "maximum number of packets acknowledged" -> "maximum number of  
> segments acknowledged"
>
> - "the number of packets transmitted" -> "the number of data  
> segments transmitted"
>
> - I'm not sure if the suggested implementation data types for each  
> variable should be mentioned; some are (N, x, af, a, z, q), and  
> others aren't.  For instance, p is clearly a floating point number,  
> but t_RTO might be understood as an integer since it's described  
> only as "in seconds".
>
> - section 2.4: "upon expiration of feedback timer" -> "upon  
> expiration of the feedback timer"
>
> - section 2.5: we should be careful about unqualified use of  
> "obsolete" since that has a specific
> meaning in the RFC series; I would add a qualifier and use a  
> different wording here like:
> "RFC 5348's Section 8.1 is therefore not relevant to the MulTFRC  
> specification." rather than the
> sentence that says "It is therefore obsolete."
>
>
> Section 3
> =========
>
> - In reading section 3.1, it leaves the reader wondering "ok, so  
> what was wrong with MulTCP?"
> since it mentions that the N-TCP emulation is the key selling point  
> rather than the smooth
> rate.
>
>
>
> Other Comments
> ==============
>
> - instead of simply titling sections as e.g. "Section 3 of RFC  
> 5348", I'd suggest also either giving some indication of the content  
> of that section or the section title itself, just so this document  
> is slightly more self-contained.
>
>
> - since this will be an IRTF document (representing a research  
> product), it would seem good to
> me to identify at the end if there are any strings dangling for  
> future research.  Some that I
> saw hinted at in the document or though of are below.
>
>
> Possible forward work:
>
> - Changing N on the fly; note this may be relevant for any N-flow  
> scheme.
>
> - TFMCC (RFC 4654) also builds upon TFRC, though is geared for  
> multicast applications.  As many multicast applications involve  
> (potentially) high-rate media, it would make sense to consider the  
> possibility of how MulTFRC and TFMCC relate (if at all), or if there  
> is overlap in the potential user bases.  The "Mul" in MulTFRC could  
> possible be confused for meaning multicast even, so it would be good  
> to call out the relationship (or lack of).
>
> - Quantifying the differences between N=1 in MulTFRC and using  
> vanilla TFRC (apologies if this is already in the thesis).
>
> --
> Wes Eddy
> MTI Systems
>
>
>> -----Original Message-----
>> From: [email-masked] [mailto:iccrg- 
>> [email-masked]] On
>> Behalf Of Michael Welzl
>> Sent: Saturday, July 31, 2010 5:33 PM
>> To: [email-masked] list
>> Subject: [Iccrg] MulTFRC update: draft-irtf-iccrg-multfrc-01
>>
>> Dear all,
>>
>> At yesterday's ICCRG meeting, I said that I would submit a minimal
>> update of our draft
>> immediately after the meeting (fixing minor syntactical issues). This
>> update is now
>> available:    http://www.ietf.org/id/draft-irtf-iccrg-multfrc-01.txt
>>
>> and here's the link to our MulTFRC website:
>> http://heim.ifi.uio.no/~michawe/research/projects/multfrc/index.html
>>
>> My first presentation of this document to ICCRG is now exactly a year
>> ago; we would
>> therefore like to move ahead with this as soon as possible now. Thus,
>> please provide
>> any comments that you may have by the end of August, preferrably
>> earlier.
>>
>> Thank you!
>>
>> Cheers,
>> Michael
>>
>>
>> _______________________________________________
>> Iccrg mailing list
>> [email-masked]
>> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP])
Date: Wed Aug  4 14:03:04 2010
Subject: [Iccrg] MulTFRC update: draft-irtf-iccrg-multfrc-01
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Here are some comments I had; none are very serious or really protocol-related, but are mostly just things that I thought would strengthen the document as an RFC.

Section 1
=========

- "not all data transfers are of equal importance to a user"; this would be more accurate as "the required delivery rates and times for all transfers are not all equal"

- between the first and second paragraphs, there's a sentence or so missing to indicate why using multiple actual flows is less desirable than a single transport flow that can emulate the congestion response of multiple actual flows.  To some extent this is in the 3rd paragraph, but it would make more sense to fully introduce the problem prior to the solution :).

- paragraph 4: "steady-state throughput of TCP" might better be "steady-state throughput of a TCP connection under the observed loss rate, RTT, and segment size.

- paragraph 4: "TFRC code" -> "TFRC pseudocode"

Section 2
=========

- section 2.1 has inconsistent spacing in the block of one-line assignments; to me, the "a = ..." form is more legible than the "af=..." form, and there's plenty of horizontal room in those lines.

- "maximum number of packets acknowledged" -> "maximum number of segments acknowledged"

- "the number of packets transmitted" -> "the number of data segments transmitted"

- I'm not sure if the suggested implementation data types for each variable should be mentioned; some are (N, x, af, a, z, q), and others aren't.  For instance, p is clearly a floating point number, but t_RTO might be understood as an integer since it's described only as "in seconds".

- section 2.4: "upon expiration of feedback timer" -> "upon expiration of the feedback timer"

- section 2.5: we should be careful about unqualified use of "obsolete" since that has a specific
meaning in the RFC series; I would add a qualifier and use a different wording here like:
"RFC 5348's Section 8.1 is therefore not relevant to the MulTFRC specification." rather than the
sentence that says "It is therefore obsolete."

Section 3
=========

- In reading section 3.1, it leaves the reader wondering "ok, so what was wrong with MulTCP?"
since it mentions that the N-TCP emulation is the key selling point rather than the smooth
rate.

Other Comments
==============

- instead of simply titling sections as e.g. "Section 3 of RFC 5348", I'd suggest also either giving some indication of the content of that section or the section title itself, just so this document is slightly more self-contained.

- since this will be an IRTF document (representing a research product), it would seem good to
me to identify at the end if there are any strings dangling for future research.  Some that I
saw hinted at in the document or though of are below.

Possible forward work:

- Changing N on the fly; note this may be relevant for any N-flow scheme.

- TFMCC (RFC 4654) also builds upon TFRC, though is geared for multicast applications.  As many multicast applications involve (potentially) high-rate media, it would make sense to consider the possibility of how MulTFRC and TFMCC relate (if at all), or if there is overlap in the potential user bases.  The "Mul" in MulTFRC could possible be confused for meaning multicast even, so it would be good to call out the relationship (or lack of).

- Quantifying the differences between N=1 in MulTFRC and using vanilla TFRC (apologies if this is already in the thesis).

--
Wes Eddy
MTI Systems

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Michael Welzl
>Sent: Saturday, July 31, 2010 5:33 PM
>To: [email-masked] list
>Subject: [Iccrg] MulTFRC update: draft-irtf-iccrg-multfrc-01
>
>Dear all,
>
>At yesterday's ICCRG meeting, I said that I would submit a minimal
>update of our draft
>immediately after the meeting (fixing minor syntactical issues). This
>update is now
>available:    http://www.ietf.org/id/draft-irtf-iccrg-multfrc-01.txt
>
>and here's the link to our MulTFRC website:
>http://heim.ifi.uio.no/~michawe/research/projects/multfrc/index.html
>
>My first presentation of this document to ICCRG is now exactly a year
>ago; we would
>therefore like to move ahead with this as soon as possible now. Thus,
>please provide
>any comments that you may have by the end of August, preferrably
>earlier.
>
>Thank you!
>
>Cheers,
>Michael
>
>
>_______________________________________________
>Iccrg mailing list
>[email-masked]
>http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg

From: [email-masked] (Michael Welzl)
Date: Wed Aug  4 09:01:00 2010
Subject: [Iccrg] Meeting minutes
Message-ID: <[email-masked]>

Hi all,

Please see the minutes taken by Andrew McGregor below, and send me any  
corrections that
you may have within the next week or so.

Thanks!

Cheers,
Michael

=========================================================

Agenda (12 July 2010) of ICCRG meeting @ IETF 78
Friday 30 July 2010, 9:00-11:30 in 0.2 Berlin

Title: RG Status
Presenter: Chairs
Time: 10 minutes

Title: "MulTFRC update (draft-irtf-iccrg-multfrc-00.txt)"
Presenter: Michael Welzl
Time: 10 minutes

(no comments)

Title: "News from CAIA's newtcp project -- delay-based TCP and improved
instrumentation of FreeBSD's TCP stack"
Presenter: Michael Welzl (on behalf of CAIA)
Time: 10 minutes

Fred Baker: the Cisco funding was me.  Reason is really the LEDBAT  
question: how do I move a whole lot of data through the network  
without destroying the ISP.  Secondly, using high-loss radios in  
things like 6lowpan, COAP where loss-based TCP really has a problem.   
Idea is to tune to the mean instead of the congestion decay cliff, so  
we can get fair sharing without attacking the network.  Therefore I'm  
very interested in congestion control that achieves this.  I asked one  
of the Contiki authors what their CC is, and reply was there is only  
one buffer and therefore there cannot be congestion.

Lars -> lawrence: please tell me you are leaving the default in BSD at  
NewReno

Lawrence Stewart -> Lars: Absolutely

Title: "TCP modifications to reduce thin-stream latency"
Presenter: Andreas Petlund
Time: 20 minutes

q: Do you have measurements on extra transmissions?

a: Answer is in the slides: about 6 to 10 %

q: Thin streams are <4 packets in flight, so all streams are thin at  
the beginning?

a: Yes

q: Bundling... when you send the second packet, how many bytes do you  
have in flight?

a: We're not tracking that

q: What about the congestion window?

a: That neither, which is work to be done.

Gorry: We're interested in streams that vary between thick and thin,  
so let's talk later.

Title: "Seeding TCP retransmission timer using SYN/SYNACK RTT sample   
(draft-ycheng-tcpm-rtosynrtt-00.txt)"
Presenter: Yu-chung Cheng
Time: 15 minutes

Gorry: Analysis is on fixed lines rather than wireless?

a: Usually on those links the SYN RTT is higher, but could be lower.

q: The SYN RTT on wireless can in fact be much higher, but it seems  
the estimator could be too high based on this.

a: We could clamp to 3s.

q: You have this 'd' in your formula representing delay for two  
packets, should you change this if the IW is 10 packets?

a: TCP typically acks every other packet, so the first ack is usually  
after receiving two packets.

q: 2988 says reset the timer after each ack, but stack may sample only  
per window.  What are the implications?

Title: "Scaling IW with Internet scale"
Presenter: Matt Mathis
Time: 10 minutes

Fred Baker: How do you expect clients to know the link buffer space?

A: They do in some cases.

Bob Briscoe: 83 SYNs for multiple objects?

A: I didn't dig through, but there were 83 SYNs

Bob: Parallel for the same object?

Tim: 83 immediately?

Matt: I didn't check how many were cascaded.

Carsten: I usually see 30-40 objects in 3-5 waves, later waves delayed  
by download of earlier.

Matt: I've spoken to these developers (both browser and site  
developers) and they do it for latency... deliberately.

Costin: A lot of these connections are there for pipelining your local  
link...

Matt: Which is why it is reasonable to have some parallelism, but not  
that much.

Aaron: What's a 'slow' link?

Matt: Coming to that

Bob: Problem here is, buffer size is getting smaller, based on long  
flows.

Matt: Those analyses are for highly aggregated links, though.

Bob: That analysis across both small and large numbers of flows is  
supposed to decrease for faster links, but to optimise startup you  
need more buffer.

Slow links are mostly NOT SHARED, and have only a couple of segments  
worth of buffer.  IW=3 is too big then.

Aaron: You're saying that there is only dumb queueing?

Matt: I'd hope not, but the paper I read did not say.

Content developers go to a lot of trouble to spread assets across  
servers.

Bob: Isn't that the same however you have multiple IWs at the same time.

Title: "A Simulation Study on Increasing TCP's IW - Preliminary Results"
Presenter: Ilpo Jaervinen
Time: 30 minutes

Bob: This is a useful presentation to give some intuition as to what  
happens.  What sort of queues were you using?

A: Tail drop

Bob: I think the results would be very different with a different kind  
of queue.

Jana: Do you have an insight as to why the fairness between bursts  
goes down at IW=10?

Richard: What kind of stack and congestion control?

A: This is ns-2, its defaults.

Title: "Increasing TCP's Initial Window  (draft-hkchu-tcpm- 
initcwn-01.txt)"
Presenter: Nandita Dukkipati
Time: 45 minutes

Fred: What was the impact on sessions competing with yours?  In other  
words, have you completely blasted the rest of the world off the  
network?

A: We can't completely answer that.

--- new speaker

Jana: TCP latency is transfer completion time?

A: Latency is time from first byte leaving to last byte acked

Costin: Why is there a dip at 60kb?

A: There are always some proxies, and there was a particular site  
skewing the data.

Richard S: You're investigating long links, high RTT, what happens if  
you run at very short RTT?

A: We also studied that, but didn't really see anything interesting.

Q: Did you see initial timeouts increase?

A: Somewhat, there is a slide on that.

Q: Are you using a linux stack?

A: Stock linux stack

Q: That stack is unique in retransmission recovery.

A: We're using a stock stack.

Q: That should be noted.

Bob: It would be better to come with the question 'what should IW be?'

Nandita: Should we be trying to find a global for the internet?

Lars: This is a TCPM proposal.  We'd like to come with a proposal for  
standardising.

Nandita: It's a great research question.

Jana: Thanks for doing all this.  I suggest that 'offered load' is too  
coarse a metric, we can talk about ways of doing something more  
realistic.

Nandita: For sure... offered load >1 is unstable.  Do you have any  
real traces?

From: [email-masked] (Lawrence Stewart)
Date: Tue Aug  3 09:18:22 2010
Subject: [Iccrg] Software for FreeBSD TCP R&D
Message-ID: <[email-masked]>

Hi all,

(apologies for any duplicates you receive and please trim the CC list
appropriately if you reply to this email)

We're pleased to announce the release of a substantial set of new
and updated BSD licenced software for TCP experimentation and research
using FreeBSD:

 - "CAIA-Hamilton Delay" Congestion Control Algorithm v0.1 (new)
 - "Hamilton Delay" Congestion Control Algorithm v0.2 (update)
 - Vegas Congestion Control Algorithm v0.2 (update)
 - H-TCP Congestion Control Algorithm v0.12 (update)
 - CUBIC Congestion Control Algorithm v0.10 (update)
 - Statistical Information For TCP Research (SIFTR) v1.2.3 (update)
 - Enhanced Round Trip Time (ERTT) Khelp Module v0.2 (update)
 - Khelp Framework for FreeBSD v0.1.1 (update)
 - Modular TCP Congestion Control for FreeBSD v0.10.0 (update)

A more detailed summary of the various tools/patches is included at the
end of this email.

Everything mentioned above along with other papers, patches and software
relevant/useful for protocol analysis, debugging and experimental
research is available from:

http://caia.swin.edu.au/urp/newtcp/tools.html

The software was developed as part of the NewTCP research
project at Swinburne University's Centre for Advanced Internet
Architectures, made possible in part by a grant from the Cisco
University Research Program Fund at Community Foundation Silicon
Valley. Testing and development was further assisted by a grant
from the FreeBSD Foundation.

We welcome any feedback and hope you enjoy playing with the code
and tools.

Cheers,
Lawrence Stewart, David Hayes and Grenville Armitage

http://caia.swin.edu.au

NB: "CAIA-Hamilton Delay" and "Hamilton Delay" are our working names for
algorithms which do not have established names in the literature.

"CAIA-Hamilton Delay" Congestion Control Algorithm v0.1 [1,2]
----------------------------------------------------------------------
A FreeBSD loadable kernel module that implements an experimental delay
based congestion control algorithm proposed by the Hamilton Institute
[3] but with modifications made by CAIA [4]. It builds on Hamilton's
initial proposal by adding tolerance to non-congestion related losses
and still aims to allow delay- and loss-based algorithms
to fairly coexist.

"Hamilton Delay" Congestion Control Algorithm v0.2 [5,6]
----------------------------------------------------------------------
A FreeBSD loadable kernel module that implements an experimental delay
based congestion control algorithm proposed by the Hamilton Institute
[3]. It provides a first step toward the ability of delay based
algorithms to fairly coexist with loss based algorithms.

Vegas Congestion Control Algorithm v0.2 [7,8]
----------------------------------------------------------------------
A FreeBSD loadable kernel module that implements the Vegas delay-based
congestion control algorithm [9].

H-TCP Congestion Control Algorithm v0.12 [10,11]
----------------------------------------------------------------------
A FreeBSD loadable kernel module that implements the H-TCP loss based
TCP congestion control algorithm [12].

CUBIC Congestion Control Algorithm v0.10 [13,14]
----------------------------------------------------------------------
A FreeBSD loadable kernel module that implements the CUBIC loss based
TCP congestion control algorithm [15]. CUBIC is the current default
algorithm used by Linux.

Statistical Information For TCP Research (SIFTR) v1.2.3 [16,17]
----------------------------------------------------------------------
A FreeBSD 6/7/8/9 kernel module that logs a range of statistics on
active TCP connections to a log file. It provides the ability to make
highly granular measurements of TCP connection state, aimed at system
administrators, developers and researchers. NB: SIFTR has been imported
into FreeBSD's "head" svn branch (a.k.a. 9-CURRENT) as revision 209662
and will be backported to 8-STABLE in time for 8.2-RELEASE.

Enhanced Round Trip Time (ERTT) Khelp Module v0.2 [18,19]
----------------------------------------------------------------------
A FreeBSD loadable kernel module that provides enhanced RTT
measurements for use by delay and rate based TCP congestion control
algorithms. Robust estimates of RTT are provided even when the receiver
uses delayed acknowledgements, TCP segmentation offload (TSO) or
Selective Acknowledgements (SACK). This module is required by the delay
based congestion control algorithms.

Khelp Framework for FreeBSD v0.1.1 [20,21]
----------------------------------------------------------------------
A FreeBSD kernel patch that provides support for generic kernel modules
known as "helpers" to hook into arbitrary points within the kernel and
provide service(s) to the running system. This forms the foundation for
the ERTT Khelp module.

Modular TCP Congestion Control for FreeBSD v0.10.0 [22,23]
-------------------------------------------------
This revision of the modular TCP congestion control framework
patch provides a current snapshot of the project's development
branch. Some fairly major changes and refactoring have gone into this
release, along with numerous tweaks, bug fixes and enhancements to
support the new delay based congestion control algorithms we have
been working on. In theory, the framework now also supports sharing of
congestion control algorithms between congestion aware transport
protocols like TCP and SCTP, though this integration work is yet to be done.

[1] http://caia.swin.edu.au/urp/newtcp/tools/cc_chd-0.1.tar.gz

[2] http://caia.swin.edu.au/urp/newtcp/tools/cc_chd-readme-0.1.txt

[3] L. Budzisz, R. Stanojevic, R. Shorten, and F. Baker, "A strategy for
fair coexistence of loss and delay-based congestion control algorithms",
IEEE Commun. Lett., vol. 13, no. 7, pp. 555-557, Jul. 2009.

[4] D. A. Hayes and G. Armitage, "Improved coexistence and loss
tolerance for delay based TCP congestion control", in Proceedings of
35th Annual IEEE Conference on Local Computer Networks (LCN 2010),
Denver, Colorado, USA, 11-14 October 2010.

[5] http://caia.swin.edu.au/urp/newtcp/tools/cc_hd-0.2.tar.gz

[6] http://caia.swin.edu.au/urp/newtcp/tools/cc_hd-readme-0.2.txt

[7] http://caia.swin.edu.au/urp/newtcp/tools/cc_vegas-0.2.tar.gz

[8] http://caia.swin.edu.au/urp/newtcp/tools/cc_vegas-readme-0.2.txt

[9] L. S. Brakmo and L. L. Peterson, "TCP Vegas: end to end
congestion avoidance on a global internet", IEEE J. Sel. Areas
Commun., vol. 13, no. 8, pp. 1465-1480, Oct. 1995.

[10] http://caia.swin.edu.au/urp/newtcp/tools/cc_htcp-0.12.tar.gz

[11] http://caia.swin.edu.au/urp/newtcp/tools/cc_htcp-readme-0.12.txt

[12] D. Leith, R. Shorten, "H-TCP: TCP for high-speed and long-distance
networks", in Second International Workshop on Protocols for Fast
Long-Distance Networks, Argonne, Illinois USA, February 2004.

[13] http://caia.swin.edu.au/urp/newtcp/tools/cc_cubic-0.10.tar.gz

[14] http://caia.swin.edu.au/urp/newtcp/tools/cc_cubic-readme-0.10.txt

[15] I. Rhee, L. Xu, S. Ha, "CUBIC for Fast Long-Distance Networks",
Internet Draft, draft-rhee-tcpm-cubic-02.txt, August 2008.

[16] http://caia.swin.edu.au/urp/newtcp/tools/siftr-1.2.3.tar.gz

[17] http://caia.swin.edu.au/urp/newtcp/tools/siftr-readme-1.2.3.txt

[18] http://caia.swin.edu.au/urp/newtcp/tools/h_ertt-0.2.tar.gz

[19] http://caia.swin.edu.au/urp/newtcp/tools/h_ertt-readme-0.2.txt

[20]
http://caia.swin.edu.au/urp/newtcp/tools/caia_khelp_framework_v0.1.1_9.x.r209905.patch

[21] http://caia.swin.edu.au/urp/newtcp/tools/khelp-readme-0.1.1.txt

[22]
http://caia.swin.edu.au/urp/newtcp/tools/caia_modularcc_v0.10.0_9.x.r209905.patch

[23] http://caia.swin.edu.au/urp/newtcp/tools/modularcc-readme-0.10.0.txt