gerrit | 8 Sep 12:11 2006
Picon
Picon

Fwd: Proposed socket API change

Hello,

apologies for cross-posting.

Message below was first posted on DCCP/Linux kernel list. I think it may be good to
discuss this subject on this list, too: apparently this topic had been discussed
before, but I can not find anything in the archive.

Gerrit

----------  FYI: Forwarded Message  ----------

Subject: Proposed socket API change
Date: Friday 08 September 2006 10:31
From: gerrit <at> erg.abdn.ac.uk
To: dccp <at> vger.kernel.org

I have the following proposal to simplify the use of the DCCP socket API
and would like to poll for opinions before  sending any patches to the list:

Suggested Change: If user doesn't want to set a service code, that's fine,
                  leave the service code associated with connection at 0.

Justification: 
In a forthcoming communication to SIGCOMM-06, the inventors of DCCP say that
they were "motivated by keeping the basic API as simple as UDP's" and that
"DCCP should provide applications with an API as simple as that of UDP".

DCCP mandates the use of service codes (RFC 4340, sec. 8.1.2). This is mirrored
in the Linux socket API by throwing an error if the application programmer
(Continue reading)

Arne Lie | 11 Sep 11:01 2006
Picon
Picon

SV: DCCP voice quality experiments

Lars Eggert,

I have read most of this report, which I find very good and interesting. I
have three questions for you:

1. What I find difficult to understand is if your applications have any
native rate adaptation, except packet drops at sender when the sender buffer
(of 5 packets?) have been saturated. Is it so that *if* (and when) TFRC
gives you an equivalent rate below G.711 rate of 95.2kbps, or 39.2kbps for
G.729, your sender WILL drop packets when using TFRC (any variant), while
the UDP system will hand the problem over to the network routers? I.e., my
main question is if G.711 and G.729 have any methods for lowering the codec
rate output below 64 and 8kbps, respectively (by quantiser scale change, or
any other means)
2. You have an experimental set-up. Why do you not also set-up real
receivers (players) so that the perceptual quality can be evaluated, instead
of, or in addition to, your "E-model R-score"
3. You use DummyNet to insert packet loss and delay. Are you considering
experimenting without DummyNet, but instead inject more real traffic to
create real router congestion? I think that will give you a more natural
environment in which you can test TFRC performance under more realistic
scenarios.

Best regards

Arne Lie
NTNU - Norway

> -----Opprinnelig melding-----
> Fra: Lars Eggert [mailto:lars.eggert <at> netlab.nec.de] 
(Continue reading)

Lars Eggert | 12 Sep 09:27 2006
Picon

Re: SV: DCCP voice quality experiments

Hi, Arne,

On Sep 11, 2006, at 11:01, Arne Lie wrote:
> 1. What I find difficult to understand is if your applications have  
> any
> native rate adaptation, except packet drops at sender when the  
> sender buffer
> (of 5 packets?) have been saturated.

the codecs we used don't change their rate in the presence of losses,  
no matter where they occur (send buffer or along the path.

> Is it so that *if* (and when) TFRC
> gives you an equivalent rate below G.711 rate of 95.2kbps, or  
> 39.2kbps for
> G.729, your sender WILL drop packets when using TFRC (any variant),  
> while
> the UDP system will hand the problem over to the network routers?

TFRC can cap the send rate at the sender, which UDP doesn't.

> I.e., my
> main question is if G.711 and G.729 have any methods for lowering  
> the codec
> rate output below 64 and 8kbps, respectively (by quantiser scale  
> change, or
> any other means)

No, see above. Tom has a draft on how codecs that adapt their rate  
may interact with DCCP.
(Continue reading)

Ingemar Johansson S (LU/EAB | 12 Sep 10:15 2006
Picon

RE: SV: DCCP voice quality experiments

Hi

Not totally updated on this issue but the AMR speech codec family can adjust the codec rate over a
relatively large range.
AMR-NB (0-4kHz audio spectum) has the bitrate range 4.75 to 12.2kbps
AMR-WB (0-8kHz audio spectum) has the bitrate range 6.60 to 23.85kbps
C-code is available at
http://www.3gpp.org/ftp/Specs/html-info/26104.htm
http://www.3gpp.org/ftp/Specs/html-info/26173.htm
Payload format is described in RFC3267

Also is available an audio codec (AMR-WB+) with bitrate range 5.2-48kbps at
http://www.3gpp.org/ftp/Specs/html-info/26304.htm
Payload format is described in RFC4352

Regards
Ingemar

> -----Original Message-----
> From: Lars Eggert [mailto:lars.eggert <at> netlab.nec.de]
> Sent: den 12 september 2006 09:27
> To: Arne Lie
> Cc: dccp <at> ietf.org
> Subject: Re: SV: [dccp] DCCP voice quality experiments
>
> Hi, Arne,
>
> On Sep 11, 2006, at 11:01, Arne Lie wrote:
> > 1. What I find difficult to understand is if your applications have
> > any native rate adaptation, except packet drops at sender when the
> > sender buffer (of 5 packets?) have been saturated.
>
> the codecs we used don't change their rate in the presence of
> losses, no matter where they occur (send buffer or along the path.
>
> > Is it so that *if* (and when) TFRC
> > gives you an equivalent rate below G.711 rate of 95.2kbps,
> or 39.2kbps
> > for G.729, your sender WILL drop packets when using TFRC (any
> > variant), while the UDP system will hand the problem over to the
> > network routers?
>
> TFRC can cap the send rate at the sender, which UDP doesn't.
>
> > I.e., my
> > main question is if G.711 and G.729 have any methods for
> lowering the
> > codec rate output below 64 and 8kbps, respectively (by
> quantiser scale
> > change, or any other means)
>
> No, see above. Tom has a draft on how codecs that adapt their
> rate may interact with DCCP.
>
> > 2. You have an experimental set-up. Why do you not also set-up real
> > receivers (players) so that the perceptual quality can be
> evaluated,
> > instead of, or in addition to, your "E-model R-score"
>
> You mean use PESQ as a metric instead of the E-model? We
> could have done that, but most related work has used the
> E-model and we wanted to more directly compare our results to
> theirs. Also, it would have required additional work and we
> were not sure that we'd get significantly more precise
> results this way.
>
> > 3. You use DummyNet to insert packet loss and delay. Are you
> > considering experimenting without DummyNet, but instead inject more
> > real traffic to create real router congestion? I think that
> will give
> > you a more natural environment in which you can test TFRC
> performance
> > under more realistic scenarios.
>
> Yes, definitely. In this first evaluation, however, we wanted
> to be able to very tightly control the environment, in order
> to be able to analyze the behavior we were seeing.
>
> We did run additional tests with multiple competing flows up
> to and past the point of congestion, to investigate the
> relative fairness of the different TFRC flavors, but these
> aren't in the current paper.
>
> Lars
> --
> Lars Eggert                                     NEC Network
> Laboratories
>
>

Attachment (smime.p7s): application/x-pkcs7-signature, 4716 bytes
Lars Eggert | 12 Sep 10:29 2006
Picon

Re: SV: DCCP voice quality experiments

Hi,

sorry if I was unclear - I didn't mean to imply that there are no  
codecs that adjust their rate, I merely meant to say that the ones  
*we used* didn't.

On Sep 12, 2006, at 10:15, Ingemar Johansson S (LU/EAB) wrote:
> Not totally updated on this issue but the AMR speech codec family  
> can adjust the codec rate over a
> relatively large range.
> AMR-NB (0-4kHz audio spectum) has the bitrate range 4.75 to 12.2kbps
> AMR-WB (0-8kHz audio spectum) has the bitrate range 6.60 to 23.85kbps
> C-code is available at
> http://www.3gpp.org/ftp/Specs/html-info/26104.htm
> http://www.3gpp.org/ftp/Specs/html-info/26173.htm
> Payload format is described in RFC3267
>
> Also is available an audio codec (AMR-WB+) with bitrate range  
> 5.2-48kbps at
> http://www.3gpp.org/ftp/Specs/html-info/26304.htm
> Payload format is described in RFC4352

Lars
--

-- 
Lars Eggert                                     NEC Network Laboratories

Attachment (smime.p7s): application/pkcs7-signature, 4957 bytes
Arne Lie | 12 Sep 10:48 2006
Picon
Picon

SV: SV: DCCP voice quality experiments

Lars,

Thanks for detailed answers. My TFRC research has been with rate adaptive
video only, and not audio so far. Ingemar: Yes, I suppose the AMR could be
of interest for many researchers when it comes to VoIP. 

I have long been working on a framework for trace driven ns-2 simulation for
real rate adaptive MPEG-4 video. My current implementation includes (among
one more) TFRC support (as of ns-2.28). The code is currently being tested
by an "external party". I will be happy to give the web address when the
code provides stable operation. The solution includes received MPEG-4 media
assembly, for PSNR calculations and visual inspection.

- Arne

> -----Opprinnelig melding-----
> Fra: Lars Eggert [mailto:lars.eggert <at> netlab.nec.de] 
> Sendt: 12. september 2006 09:27
> Til: Arne Lie
> Kopi: dccp <at> ietf.org
> Emne: Re: SV: [dccp] DCCP voice quality experiments
> 
> Hi, Arne,
> 
> On Sep 11, 2006, at 11:01, Arne Lie wrote:
> > 1. What I find difficult to understand is if your applications have 
> > any native rate adaptation, except packet drops at sender when the 
> > sender buffer (of 5 packets?) have been saturated.
> 
> the codecs we used don't change their rate in the presence of 
> losses, no matter where they occur (send buffer or along the path.
> 
> > Is it so that *if* (and when) TFRC
> > gives you an equivalent rate below G.711 rate of 95.2kbps, 
> or 39.2kbps 
> > for G.729, your sender WILL drop packets when using TFRC (any 
> > variant), while the UDP system will hand the problem over to the 
> > network routers?
> 
> TFRC can cap the send rate at the sender, which UDP doesn't.
> 
> > I.e., my
> > main question is if G.711 and G.729 have any methods for 
> lowering the 
> > codec rate output below 64 and 8kbps, respectively (by 
> quantiser scale 
> > change, or any other means)
> 
> No, see above. Tom has a draft on how codecs that adapt their 
> rate may interact with DCCP.
> 
> > 2. You have an experimental set-up. Why do you not also set-up real 
> > receivers (players) so that the perceptual quality can be 
> evaluated, 
> > instead of, or in addition to, your "E-model R-score"
> 
> You mean use PESQ as a metric instead of the E-model? We 
> could have done that, but most related work has used the 
> E-model and we wanted to more directly compare our results to 
> theirs. Also, it would have required additional work and we 
> were not sure that we'd get significantly more precise 
> results this way.
> 
> > 3. You use DummyNet to insert packet loss and delay. Are you 
> > considering experimenting without DummyNet, but instead inject more 
> > real traffic to create real router congestion? I think that 
> will give 
> > you a more natural environment in which you can test TFRC 
> performance 
> > under more realistic scenarios.
> 
> Yes, definitely. In this first evaluation, however, we wanted 
> to be able to very tightly control the environment, in order 
> to be able to analyze the behavior we were seeing.
> 
> We did run additional tests with multiple competing flows up 
> to and past the point of congestion, to investigate the 
> relative fairness of the different TFRC flavors, but these 
> aren't in the current paper.
> 
> Lars
> -- 
> Lars Eggert                                     NEC Network 
> Laboratories
> 
> 
> 

Magnus Westerlund | 12 Sep 11:29 2006
Picon

Re: SV: DCCP voice quality experiments

Lars Eggert skrev:
> 
>> 2. You have an experimental set-up. Why do you not also set-up real
>> receivers (players) so that the perceptual quality can be evaluated, 
>> instead
>> of, or in addition to, your "E-model R-score"
> 
> You mean use PESQ as a metric instead of the E-model? We could have done 
> that, but most related work has used the E-model and we wanted to more 
> directly compare our results to theirs. Also, it would have required 
> additional work and we were not sure that we'd get significantly more 
> precise results this way.
> 

I think Arne meant to actually do subjective evaluations. The issue I 
see with this is that the quality you get will be heavily dependent on 
the jitter-buffer implementation and error concealment implemented in 
the player. Using a streaming player or something similar for these 
subjective measurements would be providing results that are ignoring a 
couple of important factor, like delay.

I think if one want to have subjective results from this one need to do 
quite serious implementation that tries its best to provide high quality.

Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund <at> ericsson.com

Lars Eggert | 12 Sep 11:49 2006
Picon

Re: SV: DCCP voice quality experiments

On Sep 12, 2006, at 11:29, Magnus Westerlund wrote:
> I think Arne meant to actually do subjective evaluations.

Ah. That's what I meant by "additional work" :-)

> The issue I see with this is that the quality you get will be  
> heavily dependent on the jitter-buffer implementation and error  
> concealment implemented in the player. Using a streaming player or  
> something similar for these subjective measurements would be  
> providing results that are ignoring a couple of important factor,  
> like delay.

Right. We wanted to exclude these factors and focus (only) on the  
impact of the transport protocol on voice quality, which is why we  
used the described dynamic-programming approach to compute an optimal  
playout strategy offline.

Lars
--

-- 
Lars Eggert                                     NEC Network Laboratories

Attachment (smime.p7s): application/pkcs7-signature, 4957 bytes
Arne Lie | 12 Sep 12:57 2006
Picon
Picon

SV: SV: DCCP voice quality experiments

OK, I understand the motivation of being play-out buffer
usage independant. However, due to the strict delay-constraints
for VoIP, playout-buffer size must also be highly restricted, which
should give less differences among the different implementations. 
One exeption could of course be the advanced ones that slows down playout
speed (and adjust pitch) in the case of playout buffer draining.
- arne

> -----Opprinnelig melding-----
> Fra: Lars Eggert [mailto:lars.eggert <at> netlab.nec.de] 
> Sendt: 12. september 2006 11:50
> Til: Magnus Westerlund
> Kopi: dccp <at> ietf.org
> Emne: Re: SV: [dccp] DCCP voice quality experiments
> 
> On Sep 12, 2006, at 11:29, Magnus Westerlund wrote:
> > I think Arne meant to actually do subjective evaluations.
> 
> Ah. That's what I meant by "additional work" :-)
> 
> > The issue I see with this is that the quality you get will 
> be heavily 
> > dependent on the jitter-buffer implementation and error concealment 
> > implemented in the player. Using a streaming player or something 
> > similar for these subjective measurements would be 
> providing results 
> > that are ignoring a couple of important factor, like delay.
> 
> Right. We wanted to exclude these factors and focus (only) on 
> the impact of the transport protocol on voice quality, which 
> is why we used the described dynamic-programming approach to 
> compute an optimal playout strategy offline.
> 
> Lars
> -- 
> Lars Eggert                                     NEC Network 
> Laboratories
> 
> 
> 

Ingemar Johansson S (LU/EAB | 12 Sep 13:07 2006
Picon

RE: SV: DCCP voice quality experiments

FYI 
There is done some job in 3GPP SA-4 to impose requirements on
jitterbuffer behavior for the same reasons that you describe. The
current approach is to put limitations on both late loss and excess
delay caused by the jitterbuffer. The issue is not settled yet but the
intended outcome will be a set of requirements that a jitterbuffer
should comply with.

Ingemar

> -----Original Message-----
> From: Arne Lie [mailto:arne.lie <at> item.ntnu.no] 
> Sent: den 12 september 2006 12:58
> To: 'Lars Eggert'; Magnus Westerlund (KI/EAB)
> Cc: dccp <at> ietf.org
> Subject: SV: SV: [dccp] DCCP voice quality experiments
> 
> OK, I understand the motivation of being play-out buffer 
> usage independant. However, due to the strict 
> delay-constraints for VoIP, playout-buffer size must also be 
> highly restricted, which should give less differences among 
> the different implementations. 
> One exeption could of course be the advanced ones that slows 
> down playout speed (and adjust pitch) in the case of playout 
> buffer draining.
> - arne
> 
> > -----Opprinnelig melding-----
> > Fra: Lars Eggert [mailto:lars.eggert <at> netlab.nec.de]
> > Sendt: 12. september 2006 11:50
> > Til: Magnus Westerlund
> > Kopi: dccp <at> ietf.org
> > Emne: Re: SV: [dccp] DCCP voice quality experiments
> > 
> > On Sep 12, 2006, at 11:29, Magnus Westerlund wrote:
> > > I think Arne meant to actually do subjective evaluations.
> > 
> > Ah. That's what I meant by "additional work" :-)
> > 
> > > The issue I see with this is that the quality you get will
> > be heavily
> > > dependent on the jitter-buffer implementation and error 
> concealment 
> > > implemented in the player. Using a streaming player or something 
> > > similar for these subjective measurements would be
> > providing results
> > > that are ignoring a couple of important factor, like delay.
> > 
> > Right. We wanted to exclude these factors and focus (only) on the 
> > impact of the transport protocol on voice quality, which is why we 
> > used the described dynamic-programming approach to compute 
> an optimal 
> > playout strategy offline.
> > 
> > Lars
> > -- 
> > Lars Eggert                                     NEC Network 
> > Laboratories
> > 
> > 
> > 
> 
> 
> 


Gmane