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 cri

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 pa

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

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, K

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

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)

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 t

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 wheth

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

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,

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:

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)" <cp