Subject: [rmcat] FW: New Version Notification for draft-johansson-rmcat-scream-cc-05.txt

From: Ingemar Johansson S <[email-masked]>
Date: Tue, 3 Mar 2015 07:06:08 +0000

Hi

A new SCReAM draft is uploaded, the main change is that the proposed feedback format is changed: 
+ ACK vector is replaced by a loss counter, originally the ACK vector was considered useful as could be a useful tool to determine which RTP packet(s) to retransmit. But as RTCP already has this functionality it is no reason to duplicate it. In addition, the use of an ACK vector was a bit vulnerable to insufficient RTCP feedback rate at high video bitrates (~10Mbps) in our OpenWebRTC implementation, it is not necessarily an RTCP BW issue, it could also be that RTCP transmission is delayed due to CPU restrictions. One solution is of course to increase the size of the ACK vector or use RLE encoding but as it is of no practical use today, it was replaced by a loss counter.
+ RTP PT removed, this was earlier included due to a misunderstanding around the scope of the RTP sequence number space, as it turns out that the sequence number space is unique to a given SSRC, the RTP PT is therefore not needed.

In addition, a reference to the C++ code is added

Regards
Ingemar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: den 2 mars 2015 14:34
To: Zaheduzzaman Sarker; Ingemar Johansson S; Zaheduzzaman Sarker; Ingemar Johansson S
Subject: New Version Notification for draft-johansson-rmcat-scream-cc-05.txt

A new version of I-D, draft-johansson-rmcat-scream-cc-05.txt
has been successfully submitted by Ingemar Johansson and posted to the IETF repository.

Name:		draft-johansson-rmcat-scream-cc
Revision:	05
Title:		Self-Clocked Rate Adaptation for Multimedia
Document date:	2015-03-02
Group:		Individual Submission
Pages:		27
URL:            http://www.ietf.org/internet-drafts/draft-johansson-rmcat-scream-cc-05.txt
Status:         https://datatracker.ietf.org/doc/draft-johansson-rmcat-scream-cc/
Htmlized:       http://tools.ietf.org/html/draft-johansson-rmcat-scream-cc-05
Diff:           http://www.ietf.org/rfcdiff?url2=draft-johansson-rmcat-scream-cc-05

Abstract:
   This memo describes a rate adaptation algorithm for conversational
   video services.  The solution conforms to the packet conservation
   principle and uses a hybrid loss and delay based congestion control
   algorithm.  The algorithm is evaluated over both simulated Internet
   bottleneck scenarios as well as in a LTE (Long Term Evolution) system
   simulator and is shown to achieve both low latency and high video
   throughput in these scenarios.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Sat, 21 Mar 2015 19:12:50 +0100

Hi Ingemar, Zahed

I read the new version on the plane. I think that it has very much improved
in readability from previous versions.
Especially the relation in between the different components of the solution
are much more clear.
I hope that the following (individual) comments may be useful (take only for
what they are worth).
I have not, this time around, read all the formulas carefully though.

For some more general comments on the removal of the ACK vector please see
elsewhere.

Section 4.1, figure 1:

I  miss explanation of (3) and (4) in the figure (or can I just not find it
?).
Perhaps (3) it is the queuing delay samples on which Frame skipping is
based.

Generally I understand (1) and (3) to be the interaction towards the
application. I think
that this would be relevant to mention and actually it would be extremely
useful if this interface was described in a separate section.
Thus very clearly explaining the interraction of SCReAM with the application
layer.

As I understand the proposal there is a relation I between the Rate Control
and the congestion control which is
not illustrated in the figure. At least they rely on some of the same
congestion state variables - e.g. like in_fast_start.
Or perhaps this can better be illustrated in a different manner. This is
just a thought.

Section 4.1 last paragraph:

I don't think the consideration about whether audio or not is controlled by
RMCAT CC belongs into this section.
It may be am implementation choice in respect to how RMCAT CC is used - but
this I am not even sure about.
Anyway the consideration should not be particular to SCReAM in any manner
(or is it?) and should thus not belong in a section that
describes the decomposition of SCReAM

Section 4.1.1:

Table 2:
The description of bytes_newly_acked should be updated
I am not sure the frame_skip' variables (multiple) belongs into this table.
The frame-skipping - as far as I understand - is
almost an application layer component and not part of the CC solution as
such (or is it?)

Section 4.2 Table 4:
The ack-vector is described here. If the only purpose of this is to compute
n_loss this could be explained ?

Section 4.3 and 5:
It is not described (or is it) what makes a packet be counted as lost in
n_lost. Will n_lost decrease in re-ordering situations ?

Section 6.1:

Is the packet pacing part of the transmission control block. Could be better
explained I think. Perhaps it can also be explained
in figure 1. Is pacing truly optional/additional - or is it something that
we think an RMCAT CC solution must (SHOULD) support.
Like TCP newcwv, SCTP maxburst.  Perhaps this is a requirement question
actually..

 Section 6.2:

Perhaps this is part of the application but a feature that SCReAM supports
implementation of by the provisioning of appropriate information (age)  .

**
BR, Karen

>From: rmcat [mailto:[email-masked]] On Behalf Of Ingemar
>Johansson S
>Sent: Tuesday, March 03, 2015 8:06 AM
>To: rmcat WG ([email-masked])
>Subject: [rmcat] FW: New Version Notification for draft-johansson-rmcat-
>scream-cc-05.txt
>
>Hi
>
>+ ACK vector is replaced by a loss counter, originally the ACK vector was
>considered useful as could be a useful tool to determine which RTP
>packet(s)
>to retransmit. But as RTCP already has this functionality it is no reason
>to
>duplicate it. In addition, the use of an ACK vector was a bit vulnerable to
>insufficient RTCP feedback rate at high video bitrates (~10Mbps) in our
>OpenWebRTC implementation, it is not necessarily an RTCP BW issue, it could
>also be that RTCP transmission is delayed due to CPU restrictions. One
>solution is of course to increase the size of the ACK vector or use RLE
>encoding
>but as it is of no practical use today, it was replaced by a loss counter.
>+ RTP PT removed, this was earlier included due to a misunderstanding
>around the scope of the RTP sequence number space, as it turns out that the
>sequence number space is unique to a given SSRC, the RTP PT is therefore
>not
>needed.
>
>Status:
>https://datatracker.ietf.org/doc/draft-johansson-rmcat-scream-
>cc/
>Htmlized:
>http://tools.ietf.org/html/draft-johansson-rmcat-scream-cc-05
>Diff:
>http://www.ietf.org/rfcdiff?url2=draft-johansson-rmcat-scream-cc-
>05
>
>Abstract:
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>The IETF Secretariat

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Sun, 22 Mar 2015 21:01:36 +0000

Hi Karen,

Thanks for your comments. Please see inline below.

BR

Zahed

> 
> Section 4.1, figure 1:
> 
> I  miss explanation of (3) and (4) in the figure (or can I just not find it ?).
> Perhaps (3) it is the queuing delay samples on which Frame skipping is based.
> 
[Zaheduzzaman Sarker] yes, good catch. Thanks.

> application. I think that this would be relevant to mention and actually it
> would be extremely useful if this interface was described in a separate
> section.
[Zaheduzzaman Sarker] I think we can use the draft-ietf-rmcat-app-interaction more when describing SCReAM interaction with application when draft-ietf-rmcat-app-interaction is a bit more settled down. Hope it will be more clear then .
> and the congestion control which is not illustrated in the figure. At least they
> rely on some of the same congestion state variables - e.g. like in_fast_start.
> Or perhaps this can better be illustrated in a different manner. This is just a
> thought.
> 
> 
> It may be am implementation choice in respect to how RMCAT CC is used -
> but this I am not even sure about.
> (or is it?) and should thus not belong in a section that describes the
> decomposition of SCReAM
[Zaheduzzaman Sarker] I can agree to this. There we are just pointing to one implementation possibility but that should not indicate that Audio adaptation is not needed if SCReAM is used or SCReAM does not deal with adaptation of Audio.
> The description of bytes_newly_acked should be updated
[Zaheduzzaman Sarker] I believe you would like to have description on how this is updated, right? For now you can look at the code. Look at ScreamTx::incomingFeedback () https://github.com/EricssonResearch/scream/blob/master/code/ScreamTx.cpp 
 I am not sure the
> frame_skip' variables (multiple) belongs into this table.
> The frame-skipping - as far as I understand - is almost an application layer
> component and not part of the CC solution as such (or is it?)
[Zaheduzzaman Sarker] OK.
> n_loss this could be explained ?
[Zaheduzzaman Sarker] kind of yes, this vector is used by the receiver to identify loss of packets.
> 
> Section 4.3 and 5:
> It is not described (or is it) what makes a packet be counted as lost in n_lost.
[Zaheduzzaman Sarker] I don’t know what exactly you want to be described but if it is about some description about how one can calculate loss then we can add some text. Here you can see  A 5 packet dupThresh is implemented as receiver to count loss (see lines 57-63 in https://github.com/EricssonResearch/scream/blob/master/code/ScreamRx.cpp
> Will n_lost decrease in re-ordering situations ?
[Zaheduzzaman Sarker] NO, if you look at the implementation then you will see the loss will increase if we have large reordering (> 5 RTP sequence)
> explained I think. Perhaps it can also be explained in figure 1. Is pacing truly
> optional/additional - or is it something that we think an RMCAT CC solution
> must (SHOULD) support.
[Zaheduzzaman Sarker] For now packet pacing is not part of core SCReAM algorithm. But this sounds like more like a app-interaction discussion and a decision of where we cut the line. 
> implementation of by the provisioning of appropriate information (age)  .
[Zaheduzzaman Sarker] I am not sure I understood your point. Please explain.

---

From: Karen Elisabeth Egede Nielsen <[email-masked]>
Date: Sun, 22 Mar 2015 17:51:39 -0500

Hi,

Please see follow up below.

BR, Karen

>From: Zaheduzzaman Sarker [mailto:[email-masked]]
>Sent: Sunday, March 22, 2015 4:02 PM
>To: Karen E. E. Nielsen; Ingemar Johansson S
>Cc: rmcat WG
>Subject: RE: [rmcat] FW: New Version Notification for
>draft-johansson-rmcat-
>scream-cc-05.txt
>
>Hi Karen,
>
>> application. I think that this would be relevant to mention and
>> actually it would be extremely useful if this interface was described
>> in a separate section.
>> Thus very clearly explaining the interraction of SCReAM with the
>> application layer.
>[Zaheduzzaman Sarker] I think we can use the draft-ietf-rmcat-app-
>interaction more when describing SCReAM interaction with application when
>draft-ietf-rmcat-app-interaction is a bit more settled down. Hope it will
>be
>more clear then .
[Karen ] Yeah. I think that we could actually use the SCReAM and the Nada
proposal to
understand better what is required in terms of CC and application
interaction. Eventually
the interaction required would be exposed by the CC solution. But it is
indeed something that should be approached
from both sides in order to identify potential gaps.

>>
>> As I understand the proposal there is a relation I between the Rate
>> Control and the congestion control which is not illustrated in the
>> figure. At least they rely on some of the same congestion state
>> variables -
>e.g. like in_fast_start.
>> Or perhaps this can better be illustrated in a different manner. This
>> is just a thought.
>>
>>
>> I don't think the consideration about whether audio or not is
>> controlled by RMCAT CC belongs into this section.
>> It may be am implementation choice in respect to how RMCAT CC is used
>> - but this I am not even sure about.
>> Anyway the consideration should not be particular to SCReAM in any
>> manner (or is it?) and should thus not belong in a section that
>[Zaheduzzaman Sarker] I can agree to this. There we are just pointing to
>one
>implementation possibility but that should not indicate that Audio
>adaptation
>is not needed if SCReAM is used or SCReAM does not deal with adaptation of
>Audio.
>>
>>
>> Section 4.1.1:
>>
>> Table 2:
>[Zaheduzzaman Sarker] I believe you would like to have description on how
>this is updated, right? For now you can look at the code. Look at
>ScreamTx::incomingFeedback ()
>https://github.com/EricssonResearch/scream/blob/master/code/ScreamTx.c
>pp

[Karen ] Yes correct :-). Eventually we should have the description in the
doc.

>> The frame-skipping - as far as I understand - is almost an application
>> layer component and not part of the CC solution as such (or is it?)
>> The ack-vector is described here. If the only purpose of this is to
>> compute n_loss this could be explained ?
>> n_lost.
>[Zaheduzzaman Sarker] I don’t know what exactly you want to be described
>but if it is about some description about how one can calculate loss then
>we
>can add some text. Here you can see  A 5 packet dupThresh is implemented as
>receiver to count loss (see lines 57-63 in
>https://github.com/EricssonResearch/scream/blob/master/code/ScreamRx.c
>pp
[Karen ] Yes I think this must be described. Unless this is part of standard
RTP loss detection,
which I don't know. In the latter case one could then refer to the RTP RFC
describing this or say that loss
determination follow standard RTP loss detection mech.

>[Zaheduzzaman Sarker] NO, if you look at the implementation then you will
>see the loss will increase if we have large reordering (> 5 RTP sequence)
[Karen ] OK. I meant that if we have re-ordering larger then dupthres will a
packet counted at some point as lost, later on not
be counted as lost anymore in the returned n_lost.
>>
>> Section 6.1:
>>
>> Is the packet pacing part of the transmission control block. Could be
>> better explained I think. Perhaps it can also be explained in figure
>> 1. Is pacing truly optional/additional - or is it something that we
>> think an RMCAT CC solution must (SHOULD) support.
>> Like TCP newcwv, SCTP maxburst.  Perhaps this is a requirement
>> question actually..
>[Zaheduzzaman Sarker] For now packet pacing is not part of core SCReAM
>algorithm. But this sounds like more like a app-interaction discussion and
>a
>decision of where we cut the line.
[Karen ] Comparing with TCP and SCTP CC, I tend to think that pacing more
would be a transmission control function. But
I may can very well be wrong on this.
>>
>>  Section 6.2:
>>
>> Perhaps this is part of the application but a feature that SCReAM
>> supports implementation of by the provisioning of appropriate information
>(age)  .
[Karen ] I just meant that the frame skipping feature looks to be a
component the application might implement based on
the indications provided by SCReAM about "age" in RTP queue.   As such it
supplements SCReAM but it is not as such part of SCReAM CC.
Should it go into the Appendix of SCReAM perhaps(?)  or perhaps into the
appendix of the application interaction draft. Or am I completely wrong in
my understanding here ?

---

From: Ingemar Johansson S <[email-masked]>
Date: Mon, 23 Mar 2015 08:00:38 +0000

Hi

My additional comments inline marked with [IJ]

/Ingemar

> From: Karen Elisabeth Egede Nielsen [mailto:[email-masked]]
> Sent: den 22 mars 2015 23:52
> To: Zaheduzzaman Sarker; Ingemar Johansson S
> Cc: rmcat WG
> Subject: RE: [rmcat] FW: New Version Notification for draft-johansson-rmcat-
> scream-cc-05.txt
> 
> Hi,
> 
> >interaction more when describing SCReAM interaction with application
> >when draft-ietf-rmcat-app-interaction is a bit more settled down. Hope
> >it will be more clear then .
> proposal to understand better what is required in terms of CC and application
> interaction. Eventually the interaction required would be exposed by the CC
> solution. But it is indeed something that should be approached from both
> sides in order to identify potential gaps.
> 
> >>
> >[Zaheduzzaman Sarker] I can agree to this. There we are just pointing
> >to one implementation possibility but that should not indicate that
> >Audio adaptation is not needed if SCReAM is used or SCReAM does not
> >deal with adaptation of Audio.
> >>
> >>
> >> Section 4.1.1:
> >>
> >> Table 2:
> >[Zaheduzzaman Sarker] I believe you would like to have description on
> >how this is updated, right? For now you can look at the code. Look at
> [Karen ] Yes correct :-). Eventually we should have the description in the doc.
> 
> > I am not sure the
> >> The frame-skipping - as far as I understand - is almost an
> >> application layer component and not part of the CC solution as such
> >> (or is it?)
> >[Zaheduzzaman Sarker] I don’t know what exactly you want to be
> >described but if it is about some description about how one can
> >calculate loss then we can add some text. Here you can see  A 5 packet
> >dupThresh is implemented as receiver to count loss (see lines 57-63 in
> [Karen ] Yes I think this must be described. Unless this is part of standard RTP
> loss detection, which I don't know. In the latter case one could then refer to
> the RTP RFC describing this or say that loss determination follow standard
> RTP loss detection mech.
[IJ] Sounds OK.

> >[Zaheduzzaman Sarker] NO, if you look at the implementation then you
> >will see the loss will increase if we have large reordering (> 5 RTP
> >sequence)
> packet counted at some point as lost, later on not be counted as lost
> anymore in the returned n_lost.
[IJ] No, the current n_loss counter approach is quite simple. 
It sets a bit in the local ACK vector in the receiver if an RTP packet with a given SN is received, thus a received RTP packet is indicated by a "1" in the corresponding place, the ACK vector is also shifted right corresponding to how much the highest received sequence number advances. Loss is detected by looking for a "0" on a position in the ACK vector that is "late" enough to not trigger a spurious loss event due to reordering. A "0" means that n_loss is incremented. One improvement is that one can undo this increment if the "0" switches to a "1" later on.

> >algorithm. But this sounds like more like a app-interaction discussion
> >and a decision of where we cut the line.
> would be a transmission control function. But I may can very well be wrong
> on this.
[IJ] Actually agree with Karen here, packet pacing is integrated with the transmission scheduling in the code. What is perhaps a bit confusing here is that this was discussed before and the outcome was then that we should have a "function" in the draft that disclosed only a permissible send window and that is quite hard to combine with packet pacing. I believe that this was summarized somehow in http://www.ietf.org/mail-archive/web/rmcat/current/msg01070.html 

> appendix of the application interaction draft. Or am I completely wrong in my
> understanding here ?
[IJ] OK, with moving it to appendix