gmane.ietf.tsvwg

CFP Packet Video 2013 - Special Session on Low-LatencyInteractive Video

Stein Gjessing — 2013-05-15T15:11:41

Hi,
Here is an excellent venue for discussions and publication of results.

Cheers,
Stein
__________________________________________________________

Packet Video 2013 - Special Session on Low-Latency Interactive Video
Sponsored by IEEE Communications Society
December 12. and 13., 2013, San Jose, Ca, USA

Call for papers.

http://pv2013.itec.aau.at/call-for-papers/accepted-special-sessions/#ss1

Several years ago, it was found that users do not like video quality fluctuations. At that time the predominant belief was that network rate fluctuations should be minimized, in order to reasonably interoperate with TCP in the network. This led to the creation of a number of so-called "TCP-friendly" congestion controls that exhibit a smoother sending rate than TCP, while avoiding to send more than a conformant TCP under similar conditions. TFRC is perhaps the best known example of such a congestion control mechanism.

A lot has happened since then:
• The notion of TCP-friendliness has received massive criticism; the widespread deployment of a more aggressive TCP variant, CUBIC, has not led to an Internet meltdown, making the case that diverging from strict TCP-friendliness is possible.
• Latency minimization has become a major goal, especially in the face of “bufferbloat”: large delays from large buffers with simplistic FIFO-queue management.
• Codecs have improved; novel video codecs are able to adjust the data rate, but modern codecs may also produce variable bitrate transmissions with burstier packet flows than before.
• TFRC has been embedded in the DCCP protocol, which has probably never been used for anything other than experiments; instead of running over DCCP, RTP-based applications now contain proprietary congestion control mechanisms.

The emergence of the RTCWEB protocol suite for real-time communication between Web browsers has renewed the interest in developing congestion control standards for real-time media. This time, however, the goal is to get things right: delay should be minimized, and standards should realize congestion control using RTP with RTCP signaling. The IETF “Real-time Media Congestion Avoidance Techniques” (RMCAT) working group has been founded to address this need. New questions arise: what type of congestion controls do we need? How much feedback should we send? How do we make this work in multi-user scenarios, e.g., for video conferencing? What should be the API between a video codec and a new delay-based congestion controlled RTP stream? What is the quality that can be expected from the combination of a codec and congestion control mechanism, when we consider better metrics than plain PSNR?

Topics of interest include, but are not limited to:
• Congestion control algorithms for interactive real-time video: requirements, evaluation criteria, and mechanisms
• Necessary RTP/RTCP extensions
• Field experience with video codecs in a low-delay, real-time setting
• Interactions between applications and RTP flows
• Failing to meet real-time schedules: impact, techniques to detect, instrument or diagnose it

Organizers:
• Michael Welzl, University of Oslo (michawe at ifi.uio.no)
• Stein Gjessing, University of Oslo (steing at ifi.uio.no)

FW: NomCom 2013-2014 Call for Volunteers - CORRECTED dates in first sentence

Black, David — 2013-05-13T22:31:49

Please give some thought to participating in this year's NomCom.
This is a great way to contribute to the IETF.

Thanks,
--David


-----Original Message-----
From: ietf-announce-bounces< at >ietf.org [mailto:ietf-announce-bounces< at >ietf.org] On Behalf Of Mankin, Allison
Sent: Monday, May 13, 2013 5:27 PM
To: ietf-announce< at >ietf.org
Subject: NomCom 2013-2014 Call for Volunteers - CORRECTED dates in first sentence

The IETF nominating committee (nomcom) process for 2013-14 has begun. The 
IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB,
and the IESG. Ten voting members for the nomcom are selected in a verifiably
random way from a pool of volunteers. The more volunteers, the better chance
we have of choosing a random yet representative cross section of the IETF
population.  This year, a challenge:  let's get beyond the 100-mark for
number of volunteers.  Let's get to 200 volunteers!

The details of the operation of the nomcom can be found in RFC 3777.  
 
Volunteers must have attended 3 of the past 5 IETF meetings.  As specified in
RFC 3777, that means three out of the five past meetings up to the time this
email announcement goes out to start the solicitation of volunteers. The five
meetings out of which you must have attended three are IETF 82, 83, 84, 85, 86.

If you qualify, please volunteer.  However, much as we want this, before you 
decide to volunteer, please be sure you are willing to forgo appointment
to any of the positions for which this nomcom is responsible.  
 
The list of people and posts whose terms end with the March 2014 IETF
meeting, and thus the positions for which this nomcom is responsible, are

IAOC:
Chris Griffiths

IAB:

Bernard Aboba
Marc Blanchet
Ross Callon
Eliot Lear
Hannes Tschofenig

IESG:

Barry Leiba (Applications)
Brian Haberman (Internet)
Benoit Claise (Operations and Management)
Gonzalo Camarillo (RAI)
Stewart Bryant (Routing)
Sean Turner (Security)
Martin Stiemerling (Transport)

The primary activity for this nomcom will begin in July 2013 and should be
completed in January 2014.  The nomcom will have regularly scheduled
conference calls to ensure progress.  There will be activities to collect 
requirements from the community, review candidate questionnaires, review
feedback from community members about candidates, and talk to 
candidates.  Thus, being a nomcom member does require some time commitment.

Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours) 
June 16, 2013, as follows:

To: amankin< at >verisign.com
Subject: Nomcom 2013-14 Volunteer

Please include the following information in the email body:

 <Your Full Name>   
  // First/Given Name followed by Last/Family Name
  // matching how you enter it in the IETF Registration Form)
 <Current Primary Affiliation>
  // Typically what goes in the Company field
  // in the IETF Registration Form
[<All email addresses used to register for the past 5 IETF meetings>]
 <Preferred email address>  
 <Telephone number> 
  // For confirmation if selected

You should expect an email response from me within 3 business days stating
whether or not you are qualified.  If you don't receive this response,
please re-send your email with the tag "RESEND"" added to the subject line.

If you are not yet sure if you would like to volunteer, please consider
that nomcom members play a very important role in shaping the leadership
of the IETF. Volunteering for the nomcom is a great way to contribute
to the IETF! 

I will be publishing a more detailed target timetable, as well as details 
of the randomness seeds to be used for the RFC 3797 selection process, 
within the next couple weeks.  

Thank you!
Allison Mankin
amankin< at >verisign.com

P.S. Because the 2012-2013 nomcom is still at work, we cannot use the ietf
addresses for the nomcom chair or the nomcom committee yet, so please send
all the volunteer mail (and any questions/comments you may have) to the 
address given.

Re: QUESTION on Return of SACKs and HB ACKs

Brian F. G. Bidulock — 2013-05-09T22:19:27

Karen,

First off, I would like to discourage you from using the term
"path": SCTP has no concept of a path (largely because IP underneath
it doesn't either).  The only real choice SCTP has over how a packet
gets to the peer is by setting the destination IP address.

So consider whether packets containing response chunks should be
sent to the destination address that was provided as a source
address in the corresponding request chunk, rather than paths.

Indeed, by sending a response packet to the source address of the
packet containing the request may not take the reverse path through
the network that was traversed by the request packet at all.  In
fact, it might not even be the normal case for all but the most
trivial of networks.

Please see more comment inline...

Karen.Nielsen< at >tieto.com wrote:    (Tue, 07 May 2013 13:05:43)

IMO there no reason to send SACK and DATA to different destinations.
Bundling SACK and DATA are essential for efficiency at high
throughputs.  The "best" destination should be used for both, where
the "best" destination is the primary DATA destination for non-CMT.


CMT needs to perform some sort of gap-ack merging to suppress
spurious fast retransmit.  It can be done both at the sender and at
the receiver.  SACKs that make it out of this logic at the sender
should still be sent to the "best" destination and bundled with DATA
wherever possible.  The "best" destination in this case is
determined by the CMT distribution logic.



HB are a little different.  COOKIE-ACK, HEARTBEAT-ACK, SHUTDOWN-ACK,
SHUTDOWN-COMPLETE, ASCONF-ACK, should IMO be sent to the source
address contained in the corresponding request chunk, so long as the
destination is considered viable.  Otherwise, it should send to the
"best" destination.

These approaches work quite well in practice.

--brian

Re: QUESTION on Return of SACKs and HB ACKs

Yoshifumi Nishida — 2013-05-08T19:01:52

Hi Karen,

I'm trying to see what kind of benefits we can get by this. Do you
have some use cases?

Thanks,
--
Yoshifumi

On Tue, May 7, 2013 at 3:05 AM,  <Karen.Nielsen< at >tieto.com> wrote:

Re: 10 IW also for SCTP

Michael Tuexen — 2013-05-08T18:12:48

I agree. 
Agreed.
Agreed.

Best regards
Michael

Re: 10 IW also for SCTP

2013-05-08T13:36:25

Hi Michael,

I think that it is fair to conclude that it is not exactly clear from RFC4960 (or RFC4460) what is meant by the term

"When the time comes for the sender to transmit new DATA chunks" 

in Section 6.1. D) of RFC4960.

The communication from 

http://www.ietf.org/mail-archive/web/tsvwg/current/msg07095.html

also makes it painfully clear that consensus on the exact meaning has not been reached.

I think what at this stage we can conclude only that the Max.Burst parameter of SCTP may 
impact (limit, but not prevent) the ability of an SCTP implementation to exploit an
Initial Window larger than Max.Burst*MTU. But also that the exact limitation that the Max.Burst 
parameter constitutes in this respect will depend on the SCTP implementation.

As to the topic of deploying larger initial window for SCTP we shall see as what will come from such experiments.
I think that the feedback here was that there are no particular reasons why it should not be equally relevant to do such
for SCTP as for TCP. 

BR, Karen

Re: 10 IW also for SCTP

Michael Tuexen — 2013-05-07T22:12:24

I don't understand how using small messages instead of large messages would grow the cwnd faster than
allowed for SCTP. SCTP does ABC.
Could you explain how this works for SCTP?
Not sure I understand this... SCTP is counting the outstanding bytes. This should cover messages of different sizes.

Best regards
Michael

QUESTION on Return of SACKs and HB ACKs

2013-05-07T10:05:43

Hi,

RFC4960 in Section 6.4 opens up for the possibility that SACKs may be returned on a different path (or IP Path)
that the reflected path (or IP Path) of the incoming Data.

This, as said in RFC4960, can be the situation when a SACK acknowledges Data TSNs that have come in on different paths as well as it
 may (MAY) be a beneficial reaction if evidence is available that indicates the unavailability of the reflected data path. Such unavailability
evidence could come from arrival of duplicate Data chunks (as pointed to in RFC4960) possibly such evidence could also be established
by other means (like e.g., if HBs indicates the reflected Path to be unavailable). The latter aspect are not mentioned in RFC4960.

I am wondering, if anybody (IETF SCTP community and/or RFC4960 Authors) has any view on the validity (or the contrary) of
not returning SACKs on the reflected IP Path ?

Obviously it is very important for the path selection for return of SACKs to be as
stable and consistent as feasible, as one otherwise risks to jeopardize the validity of Data RTT measurements of peer, and using the reflected IP path
is one way to achieve this. But having said this, then I wonder if there otherwise are considered to be significant problems with the
return of SACKs via paths there are different from the reflected IP Path of Data. Issues that makes is so that an SCTP implementation should best possible prevent situations where data and SACK do not follow the same path (in opposite directions).

Possibly also the situation with return of SACKs acknowledging Data chunks that have come in on multiple paths will be even more relevant for CMT-SCTP.
This may open up for either demanding for SACKs to be returned split according to the incoming path of Data or for the recommendation of RFC4960 to use reflected path of Data to be broaden up to recommend for consistent choice of return path of SACKs.

Finally following the thoughts above for SACK return, then one may also think about the corresponding situation with the return of HB ACKs.

RFC4960 seems to assume for HB ACKs always to be returned on the reflected path of the HB as it says, Section 3.3.6, but notably the only Keyword
that applies to return of HB ACK is the SHOULD of Section 6.4 :

A HEARTBEAT ACK is always
   sent to the source IP address of the IP datagram containing the
   HEARTBEAT chunk to which this ack is responding.

Also here one can wonder as to whether it is best to have the HB ACK returned in the path over which it is most likely to reach peer or whether
it must (?) be returned on the reflect path of the incoming HB. I am not sure if the RFC4960 SHOULD here should be read mostly as a MUST or mostly as a
SHOULD unless other things make it beneficiary to use a different path ?

A BIG Thanks in Advance !

BR, Karen

Re: 10 IW also for SCTP

Mitchell Erblich — 2013-05-07T09:54:53

Hello,

Maybe I am wrong, but it seems that everyone with the emails is only considering MTU / MSS sized segments…
and that any protocol including SCTP would limit an app bursting segments onto a wire,,,

In the cases of an application initially limiting, aka pacing TCP flow, such as a fair number of wirespeed echo requests/pings,
then both protocols SHOULD NOT limit the flow and wrt to Allman's ABC, a large number of smaller segments
SHOULD then generate the sender equiv of ACK splitting…. grow the initial window faster than normal…

Thus, IMO, if the 10 or so segments are sub-MTU sized (i.e. 128bytes) and sent with some minimal spacing, I would expect to be able to grow the window faster in SS, mitigate any possible DELACKs and/or loss of ACKs….

And if at the same time, additionally while segments are placed on the wire, a few could be growing in size, additional growth can be obtained (?unfairly obtained?) while probing for the number of outstanding bytes (segments * avg size per segment) that could cause a drop (or can frags occur below MTU sized segs or … ) …. 

Mitchell Erblich


On May 6, 2013, at 6:56 AM, <Karen.Nielsen< at >tieto.com> <Karen.Nielsen< at >tieto.com> wrote:

Re: 10 IW also for SCTP

Michael Tuexen — 2013-05-06T19:54:55

True. The intention is to mitigate packet bursts. For the network it doesn't matter how the
burst are generated. So the text is generic.
Only limiting to Max.burst in the output routing would avoid bursts in response
to incoming SACks. It would not cover bursts initiated by an application calling
send in bursts. I agree, the text is not very explicit, but taking the goal into
account helps...

This goes back to burst mitigation stuff by Mark Allman. For whatever reason it
didn't make it into an TCP RFC...
Have a look at
http://www.icsi.berkeley.edu/pubs/networking/measuringinteractions05.pdf
I'm not saying that the IW is limited to value of Max.Burst. I'm saying that
the Max.Burst limitation has to be considered and results in not immediately
being able to send the whole IW.

Best regards
Michael

Re: 10 IW also for SCTP

Brian F. G. Bidulock — 2013-05-06T19:42:24

Karen,

There was some discussion on this back in 2006 in the ladder that
starts with this message:

 http://www.ietf.org/mail-archive/web/tsvwg/current/msg07054.html

--brian

Re: 10 IW also for SCTP

2013-05-06T13:56:54

Hi,

Yes, Section 6.1 D) in full reads:

"When the time comes for the sender to transmit new DATA chunks,
the protocol parameter Max.Burst SHOULD be used to limit the
number of packets sent. The limit MAY be applied by adjusting
cwnd as follows:

if((flightsize + Max.Burst*MTU) < cwnd) cwnd = flightsize +
Max.Burst*MTU

Or it MAY be applied by strictly limiting the number of packets
emitted by the output routine."

However "When the time comes for the sender to transmit new DATA chunks" is not very well specified. It certainly does not
clearly say that this assumes arrival of SACK and/or that new arrival of data from application does not initiate new transmit.

Well as specified it says that in one output routine, no more than Max.burst *MTU SHOULD be send.
If the intention was that at most Max.burst*MTU SHOULD be sent in between SACK arrival and that it is new SACK arrival that
allow for a new output routine to be initiated (or something like that), then I think this deserves to be spelled out.

A way to

If the intention of the above SHOULD is as revealed in this thread,
I would appreciate if an Errata was to be issued.

I think that it would also be good to understand the exact motivation for this limitation.

No I am not certain that IW would be limited to Max.Burst even if the above SHOULD was to be interpreted in this manner.
I suppose that the arrival of SACK would allow for new data transmit (or what else should then trick that a new output operation can be
started). If such SACK acknowledges the first 2*MTUs, I suppose that one, with an IW of 10IW, could end up having 6*MTUs outstanding now.
With IW of 4*MTU, at most 5 *MTUs could be outstanding at this point in time.

BR, Karen

Re: 10 IW also for SCTP

Michael Tuexen — 2013-05-06T12:57:10

Before that RFC 4960 says:
   D) When the time comes for the sender to transmit new DATA chunks,
      the protocol parameter Max.Burst SHOULD be used to limit the
      number of packets sent.

Assume that the application sends a lot of messages in a tight loop. Shouldn't Max.Burst
limit the number of packets sent even if IW allows for more? A way to implement this, is
given by changing cwnd as described above.
I think if an SCTP implementation implements the above SHOULD, IW would be limited to Max.Burst.
I just want to stress the point that in the case of SCTP there is Max.Burst which
has to be taken into account.

Re: 10 IW also for SCTP

2013-05-06T12:42:07

Hi,

I believe that section 6.1 D) proposes a way to implement Max.Burst in an internal routine,
not a way to limit initial CWND to 4 MTUs.

It says:

. The limit MAY be applied by adjusting
cwnd as follows:

if((flightsize + Max.Burst*MTU) < cwnd) cwnd = flightsize +
Max.Burst*MTU

Or it MAY be applied by strictly limiting the number of packets
emitted by the output routine.

So perhaps you are saying that FreeBSD implementation would effectively limit the IW to Max.Burst.
If so, this would not be the case for all SCTP implementations.

Or do you mean to say that the intention of Section 6.1 D) also was to keep the IW under Max.Burst*MTU.

That is very interesting as this sounds as to go against the TCP experiments that say that using 10 IWs is not an issue in today's networks.
Or perhaps the situations tested were situations where a high, now unused, CWND had been build up ?

Yes, I think that this is true. The same is the case for TCP.
This does depend, however, on whether one also augments the restart window and possibly
also the window (CWND/2) used after loss recovery. ( If so,
then for both, one should have to follow the prescriptions of RFC6928 of not to increase the CWND in these situations.)

It can be noted that RFC6928 does not speak about allowing the window after loss recovery to be
higher then 2MTUs (if CWND/2 <= 2MTU). The same is the case for RFC3390, but
nevertheless RFC4960 implements that the window after loss recovery does not go beneath 4 MTUs.

I do not see any such dependency from Section 6.1 D).

I don't see a huge difference between TCP

Thanks.

BR, Karen

Re: 10 IW also for SCTP

Michael Tuexen — 2013-05-06T12:15:24

It depends what you consider a burst. Do include an application calling send() in a loop,
you might want to change cwnd by the formula given in section 6.1, D). So you wouldn't send
more than 4 packets...
I think you would need to change Max.Burst at the same time. Then you should get the
same behavior. You can do the experiment...

However, Randy did some testing a while ago and reported that using Max.Burst of 4 really
helps to avoid messages being dropped.

Maybe I'm wrong, but IW of 10 just disables CC for short flows. For long living flows,
I'm not sure if the IW makes a huge difference.

Except for the Max.Burst dependency, I don't see a huge difference between TCP and SCTP.

Best regards
Michael

Re: 10 IW also for SCTP

2013-05-06T11:02:29

Hi,


But even if Max.Burst parameter is set to 4, can more than 4 full size packets be send prior to return of
SACK. Max.Burst only regulate burst, not CWND.

Do you see any reason that SCTP should not follow TCP experimental usage of 10 IWs ?

BR, Karen

Re: 10 IW also for SCTP

Michael Tuexen — 2013-05-06T10:57:20

One difference between SCTP and TCP is that SCTP uses a Max.Burst parameter. So you won't send 10 packets
without changing also the Max.Burst parameter. In the FreeBSD implementation you can tune the Max.Burst
parameter and the initial window via sysctls.

Best regards
Michael

10 IW also for SCTP

2013-05-06T10:46:34

Hi,

Experimental RFC6928 proposes to increase initial window for TCP from the 4 segments from RFC3390
to 10 segments.

From RC2960 to RFC4960, SCTP was augmented to operate with initial window of 4MTUs following RFC3390.
Indeed RFC4460 says the following:

"RFC 2960 was published with the intention of having the same
   congestion control properties as TCP.  Since the publication of RFC
   2960, TCP's initial congestion window size has been increased via RFC
   3390.  This same update will be needed for SCTP to keep SCTP's
   congestion control properties equivalent to that of TCP."

From a technical perspective there does not seem to be anything in RFC6928 that is particularly specific to TCP compared with SCTP and based on this observation I suppose that it would be equally relevant to think about introducing an equivalent experimental usage of larger IWs, up to 10MTUs, also for SCTP and to have such usage be appropriately specified at some point in time.

I wonder if this is also how the tsvwg sees this ?

Thanks!

BR, Karen

Re: feedback request: draft-thornburgh-adobe-rtmfp

Michael Thornburgh — 2013-05-03T18:41:14

there is a new revision of draft-thornburgh-adobe-rtmfp addressing the detailed on- and off-list comments and feedback from Richard Scheffenegger.  thank you Richard.

---
Filename:        draft-thornburgh-adobe-rtmfp
Revision:        07
Title:           Adobe's Secure Real-Time Media Flow Protocol
Creation date:   2013-05-02
Group:           Individual Submission
Number of pages: 107
URL:             http://www.ietf.org/internet-drafts/draft-thornburgh-adobe-rtmfp-07.txt
Status:          http://datatracker.ietf.org/doc/draft-thornburgh-adobe-rtmfp
Htmlized:        http://tools.ietf.org/html/draft-thornburgh-adobe-rtmfp-07
Diff:            http://www.ietf.org/rfcdiff?url2=draft-thornburgh-adobe-rtmfp-07
IPR:             https://datatracker.ietf.org/ipr/1942/

Abstract:
   This memo describes the Secure Real-Time Media Flow Protocol (RTMFP),
   an endpoint-to-endpoint communication protocol designed to securely
   transport parallel flows of real-time video, audio, and data
   messages, as well as bulk data, over IP networks.  RTMFP has features
   making it effective for peer-to-peer (P2P) as well as client-server
   communications, even when Network Address Translators (NATs) are
   used.
---

-michael thornburgh


[...]

Re: [aqm] Follow-up: PIE performance in cable modemenvironments

Preethi Natarajan — 2013-04-30T23:48:04

Hi,

Thank you Greg for the update and the link to the white paper.

We wanted to quickly clarify about how we tuned PIE for DOCSIS.

The basic PIE algorithm has not changed. We updated the simulation code with
the missing line mentioned below (which was a bug). The DOCSIS MAC layer has
this special nature of stop-and-go with 5ms-6ms request and grant delay.
This requires adjustment of any algorithm: for example  CoDel has to
increase its target delay from 5ms to a higher value. Similarly, our new
parameters are to make PIE adjust faster for the DOCSIS stop-and-go
behavior. Please note that eventually all these design parameters will be
automatically set, users of the PIE algorithm would not be required to set
any design parameters.

Again, many thanks for your update.
PIE team

From:  Greg White <g.white< at >CableLabs.com>
Date:  Tuesday, April 30, 2013 3:54 PM
To:  Preethi Natarajan <preethi.cis< at >gmail.com>, "iccrg< at >irtf.org"
<iccrg< at >irtf.org>, "tsvwg< at >ietf.org" <tsvwg< at >ietf.org>, "aqm< at >ietf.org"
<aqm< at >ietf.org>
Cc:  "Rong Pan (ropan)" <ropan< at >cisco.com>, "Bill Ver Steeg (versteb)"
<versteb< at >cisco.com>, "Chiara Piglione (cpiglion)" <cpiglion< at >cisco.com>,
"Mythili Suryanarayana Prabhu (mysuryan)" <mysuryan< at >cisco.com>, "Fred Baker
(fred)" <fred< at >cisco.com>, Daniel Rice <D.Rice< at >CableLabs.com>
Subject:  Re: [aqm] Follow-up: PIE performance in cable modem environments

Additionally, I've re-run my suite of simulations using the updated PIE code
from Cisco.  The results (in much more detail than I presented at ICCRG) are
documented in a white paper available here:
Active Queue Management Algorithms for DOCSIS 3.0
<http://www.cablelabs.com/downloads/pubs/Active_Queue_Management_Algorithms_
DOCSIS_3_0.pdf> 

Thanks to Preethi, Rong, et al. for debugging and tuning PIE to work well in
the cable environment, and for sharing the resulting code.

Best Regards,
Greg

From: Preethi Natarajan <preethi.cis< at >gmail.com>
Date: Tuesday, April 23, 2013 5:18 PM
To: "iccrg< at >irtf.org" <iccrg< at >irtf.org>, "tsvwg< at >ietf.org" <tsvwg< at >ietf.org>,
"aqm< at >ietf.org" <aqm< at >ietf.org>
Cc: "Rong Pan (ropan)" <ropan< at >cisco.com>, "Bill Ver Steeg (versteb)"
<versteb< at >cisco.com>, "Chiara Piglione (cpiglion)" <cpiglion< at >cisco.com>,
"Mythili Suryanarayana Prabhu (mysuryan)" <mysuryan< at >cisco.com>, "Fred Baker
(fred)" <fred< at >cisco.com>
Subject: [aqm] Follow-up: PIE performance in cable modem environments

Hello,

This is a follow-up to Greg White's (from Cable Labs) talk at the recent
ICCRG meeting on PIE's performance in cable modem environments.

Post the meeting, Greg was kind to share his ns-2 DOCSIS model with us. We
investigated PIE's performance using this model. The key items from this
investigation: 
1. Bug in PIE code: The previous PIE release (that Greg used for
evaluations) was missing a line of code. This missing line brings down drop
probability under certain conditions and turns out to be critical for the
cable modem scenario. Without this line of code, the drop probability
remains high and takes longer to come down even when the queue delay has
remained lower than the reference. The updated ns-2 PIE code can be found
here  ftp://ftpeng.cisco.com/pie/.
2. Bug in ns-2 TCP/Linux: Greg's cable modem simulations used the TCP Cubic
variant. We discovered a serious bug in ns-2 TCP/Linux Agent (confirmed by
Dr. Injong Rhee's team) that makes TCP/Cubic senders very aggressive and
unresponsive to packet drops/notifications, pretty much like UDP traffic.
Please find more details about the bug here --
http://sourceforge.net/tracker/?func=detail&aid=3608750&group_id=149743&atid
=775392.
We are working with Cable Labs to verify the cable modem results, they'll
soon be available on our FTP site along with the PIE code.

A technical paper about PIE was recently accepted at the IEEE Conference on
High Performance Switching and Routing 2013. A copy of the paper is attached
here.

The Linux PIE implementation is expected to be ready by next week and we'll
follow-up on that as well.

Many thanks,
Preethi on behalf of PIE team.

Re: [aqm] Follow-up: PIE performance in cable modemenvironments

Greg White — 2013-04-30T22:54:44

Additionally, I've re-run my suite of simulations using the updated PIE code from Cisco.  The results (in much more detail than I presented at ICCRG) are documented in a white paper available here:
Active Queue Management Algorithms for DOCSIS 3.0<http://www.cablelabs.com/downloads/pubs/Active_Queue_Management_Algorithms_DOCSIS_3_0.pdf>

Thanks to Preethi, Rong, et al. for debugging and tuning PIE to work well in the cable environment, and for sharing the resulting code.

Best Regards,
Greg

From: Preethi Natarajan <preethi.cis< at >gmail.com<mailto:preethi.cis< at >gmail.com>>
Date: Tuesday, April 23, 2013 5:18 PM
To: "iccrg< at >irtf.org<mailto:iccrg< at >irtf.org>" <iccrg< at >irtf.org<mailto:iccrg< at >irtf.org>>, "tsvwg< at >ietf.org<mailto:tsvwg< at >ietf.org>" <tsvwg< at >ietf.org<mailto:tsvwg< at >ietf.org>>, "aqm< at >ietf.org<mailto:aqm< at >ietf.org>" <aqm< at >ietf.org<mailto:aqm< at >ietf.org>>
Cc: "Rong Pan (ropan)" <ropan< at >cisco.com<mailto:ropan< at >cisco.com>>, "Bill Ver Steeg (versteb)" <versteb< at >cisco.com<mailto:versteb< at >cisco.com>>, "Chiara Piglione (cpiglion)" <cpiglion< at >cisco.com<mailto:cpiglion< at >cisco.com>>, "Mythili Suryanarayana Prabhu (mysuryan)" <mysuryan< at >cisco.com<mailto:mysuryan< at >cisco.com>>, "Fred Baker (fred)" <fred< at >cisco.com<mailto:fred< at >cisco.com>>
Subject: [aqm] Follow-up: PIE performance in cable modem environments

Hello,

This is a follow-up to Greg White's (from Cable Labs) talk at the recent ICCRG meeting on PIE's performance in cable modem environments.

Post the meeting, Greg was kind to share his ns-2 DOCSIS model with us. We investigated PIE's performance using this model. The key items from this investigation:

  1.  Bug in PIE code: The previous PIE release (that Greg used for evaluations) was missing a line of code. This missing line brings down drop probability under certain conditions and turns out to be critical for the cable modem scenario. Without this line of code, the drop probability remains high and takes longer to come down even when the queue delay has remained lower than the reference. The updated ns-2 PIE code can be found here — ftp://ftpeng.cisco.com/pie/.
  2.  Bug in ns-2 TCP/Linux: Greg's cable modem simulations used the TCP Cubic variant. We discovered a serious bug in ns-2 TCP/Linux Agent (confirmed by Dr. Injong Rhee's team) that makes TCP/Cubic senders very aggressive and unresponsive to packet drops/notifications, pretty much like UDP traffic. Please find more details about the bug here -- http://sourceforge.net/tracker/?func=detail&aid=3608750&group_id=149743&atid=775392.

We are working with Cable Labs to verify the cable modem results, they'll soon be available on our FTP site along with the PIE code.

A technical paper about PIE was recently accepted at the IEEE Conference on High Performance Switching and Routing 2013. A copy of the paper is attached here.

The Linux PIE implementation is expected to be ready by next week and we'll follow-up on that as well.

Many thanks,
Preethi on behalf of PIE team.