Subject: [Iccrg] ready-to-publish notification for draft-irtf-iccrg-welzl-congestion-control-open-research
From: [email-masked] (Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP])
Date: Wed Sep 29 16:39:49 2010

Hi Aaron, the ICCRG document on open research issues in
Internet congestion control has been through the IESG's
review and is now ready for submission to the RFC Editor.

The authors and IESG agreed on the following request to
the RFC Editor for modification of the draft prior to
publication as an RFC (which they would like the RFC
Editor to handle, rather than submit another revision):

RFC Editor Note

(1) Replace beginning of Section 3.5.3 with:

  3.5.3 Inelastic Multi-domain Pseudowires

  Extending pseudo-wires across multiple domains poses specific issues.
  Pseudowires (PW) [RFC3985] may carry non-TCP data flows (e.g. TDM
  traffic or Constant Bit Rate (CBR) ATM traffic) over a multi-domain 
  IP network. Structure Agnostic TDM over Packet (SATOP) [RFC4553], 
  Circuit Emulation over Packet Switched Networks (CESoPSN), TDM over 
  IP, are not responsive to congestion control as discussed by
  [RFC2914] (see also [RFC5033]). The same observation applies to ATM 
  circuit emulating services (CES) interconnecting CBR equipment (e.g. 
  PBX) across a Packet Switched Network (PSN).

  Moreover, it is not possible to simply reduce the flow rate of a TDM
  PW or an ATM PW when facing packet loss. Providers can rate control 
  corresponding incoming traffic but they may not be able to detect 
  that PWs carry TDM or CBR ATM traffic (mechanisms for characterizing 
  the traffic temporal properties may not necessarily be supported). 

  This can be illustrated with the following example. 

(2) Add at the end of Section 3.8.4 Congestion Control in Multi-layered Networks

  Section 3.5.3 deals with Inelastic Multi-domain Pseudowires (PW), 
  where the characteristics of the Pseudowire itself determines the 
  characteristics of the traffic crossing the multi-domain PSN 
  (and this independently of the characteristics of the traffic 
  carried in the PW). A more complex situation arises when inelastic 
  traffic is carried as part of a Pseudowire (e.g. inelastic traffic 
  over Ethernet PW over PSN) whose edges do not have the means to 
  characterize the properties of the traffic encapsulated into the
  Ethernet frames. In this case, the problem explained in 
  Section 3.5.3 is not limited to multi-domain Pseudowires but more 
  generally induced by "Pseudowire carrying inelastic traffic" (over 
  a single- or multi-domain PSN). The problem becomes even more
  intricate when the Ethernet PW carries both inelastic and 
  elastic traffic. Addressing this issue further comforts our 
  observation that a general framework to efficiently deal with 
  congestion control problems in multi-layer networks is absolutely
  necessary but without harming its evolvability.

--
Wes Eddy
MTI Systems

From: [email-masked] (Murari Sridharan)
Date: Tue Sep 21 23:53:33 2010
Subject: [Iccrg] CFP - PFLDNet
Message-ID: <[email-masked]>

Please consider submitting a paper to PFLDNet, the deadline is fast approaching (October 4 for abstracts, October 8 for position papers). As in previous years, it is co-located with ICCRG.

Thanks
Murari

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: October 4, 2010
Position paper submission: October 8, 2010
Notification of acceptance: October 27, 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):
Mark Allman, ICIR, USA
Scott Brim, Cisco, USA
Bob Briscoe, BT, UK
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
Joerg Ott, TKK, Finland
Narasimha Reddy, Texas A&M University, USA
Medy Sanadidi, UCLA, USA
Pasi Sarolahti, Aalto University, 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oakham.cs.ucl.ac.uk/pipermail/iccrg/attachments/20100921/7464d6a9/attachment-0001.html
>From [email-masked]  Wed Sep 22 08:50:18 2010
From: [email-masked] (Michael Welzl)
Date: Wed Sep 22 08:46:31 2010
Subject: [Iccrg] PFLDNeT 2010 CFP - deadline extended to 4./ 8. October!
Message-ID: <[email-masked]>

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
CFP text version: http://www.pfld.net/2010/cfp.txtScope:
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  
and 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 October 4, 2010(extended)
Position paper submission: September 27, 2010 October 8, 2010(extended)
Notification of acceptance: October 27, 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

From: [email-masked] (Ingemar Johansson S)
Date: Tue Sep 21 12:34:35 2010
Subject: [Iccrg] RE: TFRC-SP and maximum packet rate
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi

And very sorry for the delay. 
Thanks for the link to the report, it should give some answers.

An issue with modern video codecs is that they produce frames with larger differences in frame size. For instance I-frames may be so big that they need to be split up in several packets (for PMTU reasons) while B- and P-frames are considerably smaller. The effect of this is that even though the framerate of the video is 30Hz, the packet rate may be considerably higher when I-frames are transmitted.
But I guess the only way to determine how TFRC-SP works in these cases is to try it out.

Regards
/Ingemar 

> -----Original Message-----
> From: Soo-Hyun Choi [mailto:[email-masked]] 
> Sent: den 13 september 2010 14:19
> To: Ingemar Johansson S
> Cc: iccrg; [email-masked]; [email-masked]; [email-masked]
> Subject: Re: TFRC-SP and maximum packet rate
> 
> Hi,
> 
> > 
> > I have a question regarding TFRC-SP (RFC4828). It states a maximum 
> > packet rate or 100 packets/s. What was the rationale behind this 
> > restriction ?. Suppose that a 2Mbps video codec use TFRC-SP (mainly 
> > because TFRC Inter packet Interval may be difficult to 
> implement given 
> > various OS concerns). This would give a packet rate of ~170packets/s
> > 
> > My question... How does this affect the stability of TFRC-SP ?
> > 
> 
> 
> That's right - the OS's clock granularity can limit the 
> calculated TFRC rate. I would imagine that the issues with 
> the OS's clock granularity is something that you cannot get 
> away from when using a rate-based protocol.
> 
> 
> As you know, TFRC-SP, however, is mainly intended to be used 
> for a VoIP type of applications (e.g., with smaller packets). 
> In general, video packets are much bigger than the usual VoIP 
> packets, so it might be inappropriate to use it without 
> careful consideration - TFRC-SP used with 1460 bytes packet 
> size would break fairness when competing with standard TCP 
> flows (see 
> <http://icapeople.epfl.ch/widmer/tfmcc/vp-tfmcc.html> for the 
> detailed reasoning behind this). It basically says the 
> smaller the packet size, the more the flow will receive 
> bandwidth sharing (if not modifying the loss event 
> calculation method).
> 
> RFC4828 explained some of the reasoning there as well (see 
> RFC4828 Section 4.3).
> 
> 
> Cheers,
> Soo-Hyun
> 
> 
>From [email-masked]  Tue Sep 21 12:58:33 2010
From: [email-masked] (Soo-Hyun Choi)
Date: Tue Sep 21 12:54:42 2010
Subject: [Iccrg] Re: TFRC-SP and maximum packet rate
In-Reply-To: <[email-masked]>
References: <[email-masked]>
	<[email-masked]>
	<[email-masked]>
Message-ID: <[email-masked]>

Hi,

> 
> An issue with modern video codecs is that they produce frames with
> larger differences in frame size. For instance I-frames may be so big
> that they need to be split up in several packets (for PMTU reasons)
> while B- and P-frames are considerably smaller. The effect of this is
> that even though the framerate of the video is 30Hz, the packet rate
> may be considerably higher when I-frames are transmitted. But I guess
> the only way to determine how TFRC-SP works in these cases is to try
> it out.

You are right - the packet size will significantly vary depending on the
types of the frame (I, B, or, P) and video content as well. As I said
earlier, using TFRC-SP for video streams without a modification may
break the (proportional) flow-level fairness when competing with the
standard TCP flows.

There is another similar work that studied TFRC performance with the
variable packet sizes -
<http://www.icsi.berkeley.edu/ftp/pub/techreports/2000/tr-00-008.pdf>
This work also mentioned the fairness issues and solve the problem by
estimating the mean packet size (assuming PMTU is known a priori).

However, it is unclear to me as to how much the approximated packet size
is meaningful to the calculated send rate (because, the frame sizes are
so varying as we know).

I have an on-going work to solve these problems by re-introducing the
TCP-like Ack-clocking mechanism while retaining the smoothness property
in the send rate (of course, for the interactive video streaming
applications). I should be able to publish the results somewhere in the
next month or so. If you are interested, I can send you the draft copy
sometimes early next month.

Cheers,
Soo-Hyun

From: [email-masked] (Thomas Dreibholz)
Date: Tue Sep 14 18:14:25 2010
Subject: [Iccrg] Call for Papers: PAMS 2011 (deadline extended)
Message-ID: <[email-masked]>

CALL FOR PAPERS

The 1st International Workshop on Protocols and Applications with Multi-Homing
Support (PAMS)
In conjunction with the 25th IEEE International Conference on Advanced
Information Networking and Applications (AINA)
March 22-25, 2011, Singapore
http://tdrwww.iem.uni-due.de/pams2011.html

The intent of our proposed workshop is to bring together people from research
and industry, in order to provide a discussion forum for state-of-the-art
topics related to multi-homing on Network, Transport, Session and Application
Layers. The PAMS workshop will include full-paper sessions as well as a poster
session (with short presentations) to introduce preliminary ideas as well as
work in progress.

Workshops proceedings will be published by IEEE CS Conference Publishing
Service and will be included in the Digital Library.

The main topics to be addressed include (but are not limited to):

    * Network Resilience by Multi-Homing
    * Network Architectures for Multi-Homed Systems
    * Performance Evaluation of Multi-Homed Systems
    * Deployment of Multi-Homed Protocols in Existing Networks
      with Middleboxes
    * Design and Implementation of Multi-Homed Systems
    * Load Sharing and Load Balancing for Multi-Homed Systems
    * Mobility for Multi-Homed Systems
    * Protocols with Multi-Homing Support
    * Congestion and Flow Control of Multi-Homed Systems
    * Quality of Service for Multi-Homed Systems
    * Security of Multi-Homed Systems
    * Application Deployment and Support for Legacy Applications
    * Cross-Layer Optimization for Multi-Homed Systems
    * Multi-Homing in the Context of Future Internets

The proceedings will be published by IEEE Computer Society Press.

IMPORTANT DATES

    * Paper Submission Deadline: September 30, 2010 (extended)
    * Author Notification: November 1, 2010
    * Author Registration: December 3, 2010

PROGRAMME COMMITTEE

    * Nicola Altan, Cetekom, Germany
    * Paul Amer, University of Delaware, U.S.A.
    * Martin Becke, University of Duisburg-Essen, Germany
    * Holger Bleul, DB Systel, Germany
    * Anna Brunstr?m, Karlstad University, Sweden
    * Michio Honda, Keio University, Japan
    * Andreas Jungmaier, Vodafone, Germany
    * Masahiro Kozuka, Kanazawa University, Japan
    * Seok J. Koh, Kyungpook National University, Korea
    * Michael Menth, University of W?rzburg, Germany
    * Preethi Natarajan, Cisco, U.S.A.
    * Brad Penoff, University of British Columbia, Canada
    * Irene R?ngeler, M?nster University of Applied Sciences, Germany
    * Robin Seggelmann, M?nster University of Applied Sciences, Germany
    * Randall Stewart, Huawei, U.S.A.
    * Andreas Timm-Giel, TU Hamburg-Harburg, Germany
    * Esbold Unurkhaan, Mongolian University of Science and Technology, 
Mongolia
    * Alan Wagner, University of British Columbia, Canada
    * Michael Welzl, University of Oslo, Norway
    * Xing Zhou, Hainan University, China
    * Tanja Zseby, Fraunhofer FOKUS, Germany

CONTACT

For further information, please contact:
    * Thomas Dreibholz (dreibh AT iem.uni-due.de)
    * Martin Becke (martin.becke AT uni-due.de)

WEBSITE

http://tdrwww.iem.uni-due.de/pams2011.html

From: [email-masked] (Soo-Hyun Choi)
Date: Mon Sep 13 13:16:01 2010
Subject: [Iccrg] Re: TFRC-SP and maximum packet rate
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

> 
> I have a question regarding TFRC-SP (RFC4828). It states a maximum
> packet rate or 100 packets/s. What was the rationale behind this
> restriction ?. Suppose that a 2Mbps video codec use TFRC-SP (mainly
> because TFRC Inter packet Interval may be difficult to implement
> given various OS concerns). This would give a packet rate of
> ~170packets/s
> 
> My question... How does this affect the stability of TFRC-SP ?
> 

That's right - the OS's clock granularity can limit the calculated TFRC
rate. I would imagine that the issues with the OS's clock granularity is
something that you cannot get away from when using a rate-based protocol.

As you know, TFRC-SP, however, is mainly intended to be used for a VoIP
type of applications (e.g., with smaller packets). In general, video
packets are much bigger than the usual VoIP packets, so it might be
inappropriate to use it without careful consideration - TFRC-SP used
with 1460 bytes packet size would break fairness when competing with
standard TCP flows (see
<http://icapeople.epfl.ch/widmer/tfmcc/vp-tfmcc.html> for the detailed
reasoning behind this). It basically says the smaller the packet size,
the more the flow will receive bandwidth sharing (if not modifying the
loss event calculation method).

RFC4828 explained some of the reasoning there as well (see RFC4828
Section 4.3).

Cheers,
Soo-Hyun

From: [email-masked] (Ingemar Johansson S)
Date: Mon Sep 13 07:16:40 2010
Subject: [Iccrg] TFRC-SP and maximum packet rate
Message-ID: <[email-masked]>

Hi

I have a question regarding TFRC-SP (RFC4828). It states a maximum packet rate or 100 packets/s. What was the rationale behind this restriction ?.
Suppose that a 2Mbps video codec use TFRC-SP (mainly because TFRC Inter packet Interval may be difficult to implement given various OS concerns). This would give a packet rate of ~170packets/s

My question... How does this affect the stability of TFRC-SP ?

Regards
Ingemar

=================================
INGEMAR JOHANSSON  M.Sc. 
Senior Research Engineer 

Ericsson AB
Multimedia Technologies
Labratoriegr?nd 11
971 28, Lule?, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]
www.ericsson.com 
Visit http://labs.ericsson.com !
=================================

From: [email-masked] (Ingemar Johansson S)
Date: Fri Sep 10 13:35:37 2010
Subject: [Iccrg] TFRC and RTP
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi

Thanks for the prompt response. 
Yes it is true that one can use "Reduced size RTCP". In practice it would then mean that and RTCP SR (or RR) without the SDES-CNAME entity. The RTCP packets will anyway become relatively bulky and that will reduce the RTCP rate.

I will have a closer look at Colin's work

/Ingemar

> -----Original Message-----
> From: Soo-Hyun Choi [mailto:[email-masked]] 
> Sent: den 10 september 2010 14:29
> To: Ingemar Johansson S
> Cc: [email-masked]; iccrg; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [Iccrg] TFRC and RTP
> 
> Hi,
> 
> > 
> > I am in the process where I try to understand TFRC (and the 
> modifications like TFRC-SP and MulTFRC) better and in 
> particular how they can be used with RTP.
> > RTP is assumed to use RTCP as feedback protocol. The rate 
> of the RTCP feedback is given by the alloacted RTCP 
> bandwidth, I would expect that in the majority of cases the 
> time between RTCP is considerably longer than RTT.
> > 
> 
> You could potentially use your proposed standard to meet this 
> requirement? -- http://tools.ietf.org/html/rfc5506
> 
> 
> 
> > This gives as I see it two potential problems
> > + Estimation of RTT, RTT will be subsampled.
> > + Loss events. The traditional RTCP report blocks does not 
> make it possible to determine this reliably. The ECN for RTP 
> draft 
> (http://tools.ietf.org/id/draft-ietf-avt-ecn-for-rtp-02.txt) 
> specifies a NACK feedback packet that can be transitted in 
> early or immediate mode. This should make it possible to 
> determine the loss events but the accuracy will then depend 
> on the estimate of RTT.
> > 
> > Does anybody have an idea about how the limitations above 
> (esp the subsampled RTT) will affect TFRC ?
> > 
> 
> Because the measured RTT (SRTT) is inversely proportional to 
> the computed rate directly, the sub-sampled RTT would 
> certainly affect the calculated rate to some degree, e.g., it 
> could be of less smooth as one would hoped, or the computed 
> rate is limited by the sub-sampled RTT in a local LAN 
> environment (when RTT is extremely small).
> 
> The workaround to solve this might be (1) create a new 
> suitable AVPF packet to report RTT for TFRC feedback purpose 
> or (2) use an ack-clock based congestion control.
> 
> One of the students with Colin Perkins has investigated 
> similar problems to this earlier: http://csperkins.org/research/cc/
> -- see "TCP Friendly Rate Control" section there.
> 
> 
> Cheers,
> Soo-Hyun
> 
> 
>From [email-masked]  Mon Sep 13 06:46:06 2010
From: [email-masked] (Ingemar Johansson S)
Date: Mon Sep 13 06:43:28 2010
Subject: [Iccrg] MulTFRC and TFRC-SP
Message-ID: <[email-masked]>

Hi

I have one question regarding MulTFRC. The spec says that it is based on TFRC (RFC5348). 

My question.. Can MulTFRC be used with TFCR-SP (RFC4828) ? 
Are there any special issues that muct be considered ?

/Ingemar
=================================
INGEMAR JOHANSSON  M.Sc. 
Senior Research Engineer 

Ericsson AB
Multimedia Technologies
Labratoriegr?nd 11
971 28, Lule?, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]
www.ericsson.com 
Visit http://labs.ericsson.com !
=================================

From: [email-masked] (Soo-Hyun Choi)
Date: Fri Sep 10 13:26:28 2010
Subject: [Iccrg] TFRC and RTP
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

> 
> I am in the process where I try to understand TFRC (and the modifications like TFRC-SP and MulTFRC) better and in particular how they can be used with RTP.
> RTP is assumed to use RTCP as feedback protocol. The rate of the RTCP feedback is given by the alloacted RTCP bandwidth, I would expect that in the majority of cases the time between RTCP is considerably longer than RTT.
> 

You could potentially use your proposed standard to meet this
requirement? -- http://tools.ietf.org/html/rfc5506

> This gives as I see it two potential problems
> + Estimation of RTT, RTT will be subsampled.
> + Loss events. The traditional RTCP report blocks does not make it possible to determine this reliably. The ECN for RTP draft (http://tools.ietf.org/id/draft-ietf-avt-ecn-for-rtp-02.txt) specifies a NACK feedback packet that can be transitted in early or immediate mode. This should make it possible to determine the loss events but the accuracy will then depend on the estimate of RTT.
> 
> Does anybody have an idea about how the limitations above (esp the subsampled RTT) will affect TFRC ?
> 

Because the measured RTT (SRTT) is inversely proportional to the
computed rate directly, the sub-sampled RTT would certainly affect the
calculated rate to some degree, e.g., it could be of less smooth as one
would hoped, or the computed rate is limited by the sub-sampled RTT in a
local LAN environment (when RTT is extremely small).

The workaround to solve this might be (1) create a new suitable AVPF
packet to report RTT for TFRC feedback purpose or (2) use an ack-clock
based congestion control.

One of the students with Colin Perkins has investigated similar problems
to this earlier: http://csperkins.org/research/cc/
-- see "TCP Friendly Rate Control" section there.

Cheers,
Soo-Hyun

From: [email-masked] (Ingemar Johansson S)
Date: Fri Sep 10 12:43:07 2010
Subject: [Iccrg] TFRC and RTP
Message-ID: <[email-masked]>

Hi

I am in the process where I try to understand TFRC (and the modifications like TFRC-SP and MulTFRC) better and in particular how they can be used with RTP.
RTP is assumed to use RTCP as feedback protocol. The rate of the RTCP feedback is given by the alloacted RTCP bandwidth, I would expect that in the majority of cases the time between RTCP is considerably longer than RTT.

This gives as I see it two potential problems
+ Estimation of RTT, RTT will be subsampled.
+ Loss events. The traditional RTCP report blocks does not make it possible to determine this reliably. The ECN for RTP draft (http://tools.ietf.org/id/draft-ietf-avt-ecn-for-rtp-02.txt) specifies a NACK feedback packet that can be transitted in early or immediate mode. This should make it possible to determine the loss events but the accuracy will then depend on the estimate of RTT.

Does anybody have an idea about how the limitations above (esp the subsampled RTT) will affect TFRC ?

Regards
/Ingemar

=================================
INGEMAR JOHANSSON  M.Sc. 
Senior Research Engineer 

Ericsson AB
Multimedia Technologies
Labratoriegr?nd 11
971 28, Lule?, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]
www.ericsson.com 
Visit http://labs.ericsson.com !
=================================

From: [email-masked] (Thomas Dreibholz)
Date: Thu Sep  9 20:37:29 2010
Subject: [Iccrg] Call for Papers: Int'l Workshop on Protocols and Applications with Multi-Homing Support (PAMS)
Message-ID: <[email-masked]>

CALL FOR PAPERS

The 1st International Workshop on Protocols and Applications with Multi-Homing 
Support (PAMS)
In conjunction with the 25th IEEE International Conference on Advanced 
Information Networking and Applications (AINA)
March 22-25, 2011, Singapore
http://tdrwww.iem.uni-due.de/pams2011.html

The intent of our proposed workshop is to bring together people from research
and industry, in order to provide a discussion forum for state-of-the-art 
topics related to multi-homing on Network, Transport, Session and Application
Layers. The PAMS workshop will include full-paper sessions as well as a poster
session (with short presentations) to introduce preliminary ideas as well as 
work in progress.

Workshops proceedings will be published by IEEE CS Conference Publishing
Service and will be included in the Digital Library.

The main topics to be addressed include (but are not limited to):

    * Network Resilience by Multi-Homing
    * Network Architectures for Multi-Homed Systems
    * Performance Evaluation of Multi-Homed Systems
    * Deployment of Multi-Homed Protocols in Existing Networks with 
Middleboxes
    * Design and Implementation of Multi-Homed Systems
    * Load Sharing and Load Balancing for Multi-Homed Systems
    * Mobility for Multi-Homed Systems
    * Protocols with Multi-Homing Support
    * Congestion and Flow Control of Multi-Homed Systems
    * Quality of Service for Multi-Homed Systems
    * Security of Multi-Homed Systems
    * Application Deployment and Support for Legacy Applications
    * Cross-Layer Optimization for Multi-Homed Systems
    * Multi-Homing in the Context of Future Internets

IMPORTANT DATES

    * Paper Submission Deadline: September 15, 2010
    * Author Notification: November 1, 2010
    * Author Registration: December 3, 2010

The proceedings will be published by IEEE Computer Society Press.

For further information, please contact:
    * Thomas Dreibholz (dreibh AT iem.uni-due.de)
    * Martin Becke (martin.becke AT uni-due.de)

WEBSITE

http://tdrwww.iem.uni-due.de/pams2011.html

From: [email-masked] (Murari Sridharan)
Date: Thu Sep  2 06:58:33 2010
Subject: [Iccrg] review of high-speed proposals?
In-Reply-To: <AANLkTi=SpFhoE9-DK1+hk=[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <AANLkTi=SpFhoE9-DK1+hk=[email-masked]>
Message-ID: <[email-masked]>

Sure, as I said earlier this year to Wes and Lars, we are ready to take this to tcpm, but after this review was forwarded to TCPM there was no activity around the high speed proposals may be because they were quite busy with TCP auth and other such proposals. 

Thanks

-----Original Message-----
From: Lachlan Andrew [mailto:[email-masked]] 
Sent: Tuesday, August 31, 2010 9:00 PM
To: Murari Sridharan
Cc: Lars Eggert; [email-masked] list
Subject: Re: [Iccrg] review of high-speed proposals?

Greetings Murari,

The ICCRG is part of the IRTF, not IETF.  Our review is just input to the IETF's working group...

Cheers,
Lachlan

On 1 September 2010 13:41, Murari Sridharan <[email-masked]> wrote:
> Yes, I'll take a look at the final review and see if the doc needs to be updated. Hasn't IETF already reviewed it under ICCRG?
>
> Thanks
>
> -----Original Message-----
> From: Lars Eggert [mailto:[email-masked]]
> Sent: Tuesday, August 31, 2010 12:24 AM
> To: [email-masked] list; Injong Rhee; Murari Sridharan; Douglas 
> Leith
> Cc: Michael Welzl; Thomas Narten
> Subject: Re: [Iccrg] review of high-speed proposals?
>
> 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>
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>

--
Lachlan Andrew? Centre for Advanced Internet Architectures (CAIA) Swinburne University of Technology, Melbourne, Australia <http://caia.swin.edu.au/cv/landrew>
Ph +61 3 9214 4837

From: [email-masked] (Lachlan Andrew)
Date: Wed Sep  1 04:58:57 2010
Subject: [Iccrg] review of high-speed proposals?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <AANLkTi=SpFhoE9-DK1+hk=[email-masked]>

Greetings Murari,

The ICCRG is part of the IRTF, not IETF.  Our review is just input to
the IETF's working group...

Cheers,
Lachlan

On 1 September 2010 13:41, Murari Sridharan <[email-masked]> wrote:
> Yes, I'll take a look at the final review and see if the doc needs to be updated. Hasn't IETF already reviewed it under ICCRG?
>
> Thanks
>
> -----Original Message-----
> From: Lars Eggert [mailto:[email-masked]]
> Sent: Tuesday, August 31, 2010 12:24 AM
> To: [email-masked] list; Injong Rhee; Murari Sridharan; Douglas Leith
> Cc: Michael Welzl; Thomas Narten
> Subject: Re: [Iccrg] review of high-speed proposals?
>
> 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>
>
>
> _______________________________________________
> Iccrg mailing list
> [email-masked]
> http://oakham.cs.ucl.ac.uk/mailman/listinfo/iccrg
>

-- 
Lachlan Andrew? Centre for Advanced Internet Architectures (CAIA)
Swinburne University of Technology, Melbourne, Australia
<http://caia.swin.edu.au/cv/landrew>
Ph +61 3 9214 4837

From: [email-masked] (Murari Sridharan)
Date: Wed Sep  1 04:40:39 2010
Subject: [Iccrg] review of high-speed proposals?
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Yes, I'll take a look at the final review and see if the doc needs to be updated. Hasn't IETF already reviewed it under ICCRG?

Thanks

-----Original Message-----
From: Lars Eggert [mailto:[email-masked]] 
Sent: Tuesday, August 31, 2010 12:24 AM
To: [email-masked] list; Injong Rhee; Murari Sridharan; Douglas Leith
Cc: Michael Welzl; Thomas Narten
Subject: Re: [Iccrg] review of high-speed proposals?

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>