Subject: Re: [iccrg] Presentation on Sprout at today's ICCRG

From: Keith Winstein <[email-masked]>
Date: Tue, 5 Nov 2013 13:23:06 -0500

Hello Zahed,

Thanks for sending! I'm afraid I wasn't able to find a previous email from
you.

This is very interesting -- I would love to see the implementation of how
your team grafted the periodic data source to the Sprout sender. I assume
you modified "sproutbt2" (Sprout "bulk transport") but wanted to
double-check. Is your code available for us to take a look?

I agree with you that having a sender that only produces data periodically
is considerably tougher than "bulk transport," or at least that it
introduces more tradeoffs into the design. Sprout has a few tools to deal
with this kind of issue --

(1) The "time_to_next" header field, which tells the receiver when it
should expect the next datagram. The receiver uses this to decide whether
it should count a gap in packets received against the capacity of the
network or just as an indication that none have been sent. Did your team
set this to 1/30 second for the last datagram in a flight, or how did you
adjust it? It may take tuning, especially if there is some latency in
coming up with the next flight (next coded frame).

(2) Buffering 1-2 frames at the sender. This is the easiest way to make
sure there is always data available to send! Of course there is a tradeoff
between latency and throughput, which is sort of the basic message of the
Sprout work. But you probably do not literally want your coded video frame
sizes to be bouncing around as fast as Sprout's network forecasts, so it
would be better to have 1-2 frames of sender-side buffering (at 60 fps) and
adjust the video coder a bit more smoothly.

(3) Sampling from the video camera more often (generally 60 fps) and only
plucking frames off the camera and coding them when there is (enough)
capacity available in Sprout's forecast to fire off a good-quality frame.
The slower the camera generates frames (e.g. 30 Hz in your case), the
harder it is to fill the link. Especially if you don't buffer anything at
the sender.

Thanks again for your interest -- we'd be eager to try your code in our
emulation environment and see if we can get Sprout to do better with a
"periodic" source.

Best regards,
Keith

On Tue, Nov 5, 2013 at 12:53 PM, Zaheduzzaman Sarker <
[email-masked]> wrote:

>  Hi Keith,
>
>
>
> My apologies if I have not send you the slides already. I thought I send
> something to you (the mail address from the web site) on last Sunday and
> asking your comment on the slides.
>
>
>
> This work is done by one of our MS thesis student. I found it interesting
> and he was also wondering if you guys have also seen this and if there is
> any fix for it.
>
> Please bear in mind that the presentation is not to show Sprout is not
> working rather showing what could go wrong if the periodicity and data
> limitation is not taken into consideration.
>
>
>
> Anyway, Here the slides. I would appreciate any comments from you.
>
>
>
> BR
>
>
>
> Zahed
>
>
>
>
> *===============================================================================*
>
> *ANM ZAHEDUZZAMAN SARKER *
> Senior Researcher
> Multimedia Technologies
>
>
> *Ericsson*
> Laboratoriegränd 11
> 97128 Luleå, Sweden
> Phone +46 10 717 37 43
> Mobile +46 76 115 37 43
> Office +46 76 115 37 43
> Fax +46 920 996 21
> [email-masked]
> www.ericsson.com
>
>
> ===============================================================================
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Keith
> Winstein
> *Sent:* den 5 november 2013 09:44
> *To:* Zaheduzzaman Sarker
> *Cc:* [email-masked]; Hari Balakrishnan; Anirudh Sivaraman
> *Subject:* Presentation on Sprout at today's ICCRG
>
>
>
> Hello,
>
>
>
> Just saw you are presenting an evaluation of Sprout at today's ICCRG at
> the IETF meeting. That's great! We appreciate your interest.
>
>
>
> Unfortunately I'm not attending this IETF -- can you please send me a copy
> of your slides and any conclusions you have found? I'm eager to learn more.
>
>
>
> Best regards, and thank you,
>
> Keith
>
>
>

---

From: Zaheduzzaman Sarker <[email-masked]>
Date: Fri, 15 Nov 2013 12:06:35 +0100

Hi Keith,

Sorry for late reply.

Nikolas is finalizing his thesis now. He has implemented some ideas to 
improve Sprout which he calls "E-Sprout". Soon he will publish his 
thesis and you will get to know more about it. He has implemented 
similar ideas like 1) and 2) you mentioned. According to the results it 
was not good enough to improve the Sprout by just doing 1) or 2).

please see inline below for some answers to your questions.

BR

Zahed

On 2013-11-05 19:23, Keith Winstein wrote:
> Hello Zahed,
>
> Thanks for sending! I'm afraid I wasn't able to find a previous email
> from you.
>
> This is very interesting -- I would love to see the implementation of
> how your team grafted the periodic data source to the Sprout sender. I
> assume you modified "sproutbt2" (Sprout "bulk transport") but wanted to
Basically the tunnel version of Sprout is implemented in our 
propitiatory LTE Simulator (this was available in the Sprout website). 
If you want to about how we model the periodic data source then you can 
have a look at my presentation in RMCAT WG 
http://www.ietf.org/proceedings/88/slides/slides-88-rmcat-9.pdf.

>
> I agree with you that having a sender that only produces data
> periodically is considerably tougher than "bulk transport," or at least
> that it introduces more tradeoffs into the design. Sprout has a few
> tools to deal with this kind of issue --
>
> should expect the next datagram. The receiver uses this to decide
> whether it should count a gap in packets received against the capacity
> of the network or just as an indication that none have been sent. Did
> your team set this to 1/30 second for the last datagram in a flight, or
> how did you adjust it?
yes it was set to the framerate.
It may take tuning, especially if there is some
> latency in coming up with the next flight (next coded frame).
>
> sure there is always data available to send! Of course there is a
> tradeoff between latency and throughput, which is sort of the basic
> message of the Sprout work. But you probably do not literally want your
> coded video frame sizes to be bouncing around as fast as Sprout's
> network forecasts, so it would be better to have 1-2 frames of
> sender-side buffering (at 60 fps) and adjust the video coder a bit more
> smoothly.
yes, buffering is also done as the sender but the frames were not hold 
back unnecessarily.
>
> (3) Sampling from the video camera more often (generally 60 fps) and
> only plucking frames off the camera and coding them when there is
> (enough) capacity available in Sprout's forecast to fire off a
> good-quality frame. The slower the camera generates frames (e.g. 30 Hz
> in your case), the harder it is to fill the link. Especially if you
> don't buffer anything at the sender.
This might work however I don't know how this fits into the Sprout 
framework. Here you are talking about a direct relation between camera, 
encoder and congestion control algorithm (in case of Sprout the 
transport protocol) which might be needed for a transport congestion 
control algorithm to work. In RMCAT there have been discussions around 
this please join those discussion if possible.
> On Tue, Nov 5, 2013 at 12:53 PM, Zaheduzzaman Sarker
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Keith,____
>
>     __ __
>
>     My apologies if I have not send you the slides already. I thought I
>     send something to you (the mail address from the web site) on last
>     Sunday and asking your comment on the slides.____
>
>     __ __
>
>     This work is done by one of our MS thesis student. I found it
>     interesting and he was also wondering if you guys have also seen
>     this and if there is any fix for it.____
>
>     Please bear in mind that the presentation is not to show Sprout is
>     not working rather showing what could go wrong if the periodicity
>     and data limitation is not taken into consideration.____
>
>     __ __
>
>     Anyway, Here the slides. I would appreciate any comments from you.____
>
>     __ __
>
>     BR____
>
>     __ __
>
>     Zahed____
>
>     __ __
>
>     *===============================================================================____*
>
>     Multimedia Technologies____
>
>
>     *Ericsson*
>     Laboratoriegränd 11
>     97128 Luleå, Sweden
>     Phone +46 10 717 37 43 <tel:%2B46%2010%20717%2037%2043>
>     Mobile +46 76 115 37 43 <tel:%2B46%2076%20115%2037%2043>
>     Office +46 76 115 37 43 <tel:%2B46%2076%20115%2037%2043>
>     Fax +46 920 996 21 <tel:%2B46%20920%20996%2021>
>     <mailto:[email-masked]>
>     www.ericsson.com <http://www.ericsson.com>____
>
>     ===============================================================================____
>
>     __ __
>
>     *From:[email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] *On Behalf
>     Of *Keith Winstein
>     *Cc:* [email-masked] <mailto:[email-masked]>; Hari Balakrishnan;
>     Anirudh Sivaraman
>     *Subject:* Presentation on Sprout at today's ICCRG____
>
>     __ __
>
>     Hello,____
>
>     __ __
>
>     Just saw you are presenting an evaluation of Sprout at today's ICCRG
>     at the IETF meeting. That's great! We appreciate your interest.____
>
>     __ __
>
>     Unfortunately I'm not attending this IETF -- can you please send me
>     a copy of your slides and any conclusions you have found? I'm eager
>     to learn more.____
>
>     __ __
>
>     Best regards, and thank you,____
>
>     Keith____
>
>     __ __
>
>

-- 

Zahed

==================================================
ANM ZAHEDUZZAMAN SARKER

Ericsson AB
Multimedia Technologies
Laboratoriegränd 11
97128 Luleå, Sweden
Phone +46 10 717 37 43
Fax +46 920 996 21
SMS/MMS +46 76 115 37 43

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

---

From: Keith Winstein <[email-masked]>
Date: Fri, 15 Nov 2013 19:20:08 -0500

Thanks Zahed. Very interesting -- we'll be eager to see and test the code
when it is available.

Have you run the unmodified sproutbt2 in your LTE simulator? Separate from
the difficulties created by these periodic sources, I am curious if there
is any substantive difference between our results (in an emulated LTE
network, based on a trace of Verizon and AT&T's LTE networks) and yours (in
the LTE simulator).

Best regards,
Keith

On Fri, Nov 15, 2013 at 6:06 AM, Zaheduzzaman Sarker <
[email-masked]> wrote:

> improve Sprout which he calls "E-Sprout". Soon he will publish his thesis
> and you will get to know more about it. He has implemented similar ideas
> like 1) and 2) you mentioned. According to the results it was not good
> enough to improve the Sprout by just doing 1) or 2).
>
> Basically the tunnel version of Sprout is implemented in our propitiatory
> LTE Simulator (this was available in the Sprout website). If you want to
> about how we model the periodic data source then you can have a look at my
> presentation in RMCAT WG http://www.ietf.org/proceedings/88/slides/slides-
> 88-rmcat-9.pdf.
>
>
>
> encoder and congestion control algorithm (in case of Sprout the transport
> protocol) which might be needed for a transport congestion control
> algorithm to work. In RMCAT there have been discussions around this please
> join those discussion if possible.
>
>>