|
List Info
Thread: Re: RDT specifications
|
|
| Re: RDT specifications |
  United States |
2008-03-17 00:46:41 |
|
There is no logical reason for the client to behave like this. It is
possible that this is a bug, but you would need to narrow down the repro
case a little bit.
Are you up for fixing this bug yourself? If you were, then we could
provide you the necessary pointers on this mailing list.
Thanks,
Rishi.
At 09:04 AM 3/10/2008, vlemaire.ext orange-ftgroup.com wrote:
Content-class:
urn:content-classes:message
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C882C8.7B7D4E1B"
Hi,
I contact you because I don't
find any clear documentation about the rate adaptation mechanism I
observe on my network.
Here is a short description of my problem.
I'm analysing my network performances on streaming applications over
RDT/UDP. The public backbone as no throughput restriction, my private
network is limited to 32kb/s in uplink and downlink. I'm trying to watch
a video encoded with 100kb/s using streaming RDT/UDP. I repeat 10 times
the same scenario in the same conditions, 8 times out of 10 attemps I
observe the behaviour "A" and 75% of the packets lost, and the
2 attemps left I observe the behaviour "B" and 65% lost.
- behaviour "A" : the throughput on the backbone side stays at
150kb/s during all the transfer, the client reports ACK every second and
NACK for each message missing.
- behaviour "B" : the throughput is 150kb/s, the client reports
ACK every second and NACK for each missing message (like for
"A") but only during the first 15 seconds of the transfer, then
the client stops sending both ACK and NACK and the data rate on the
backbone side slows down to 100kb/s until the end of the transfer (why
?!).
Do you have any idea of what
happens or any suggestion of documentation I could read to investigate
the cause of this.
Thanks for your help
Regards
Vincent
De : Rishi Mathew
[ rmathew real.com" eudora="autourl">
mailto:rmathew real.com]
Envoyé : lundi 10 mars 2008 16:39
À : zze-EQOS LEMAIRE V ext RD-RESA-ISS
Cc : protocol-dev helixcommunity.org
Objet : Re: [hxadmin] RDT specifications
Hi Vincent,
RDT v1 was deprecated a while back and completely replaced by v2&v3.
There should be no servers in the market today using v1.
If you are seeing some kind of rate adaptation mechanism as you mention,
then the client/server is using v3 (which was when rate adaptation was
introduced).
I have cc'ed the mailing list where you can ask further
questions.
Cheers,
Rishi.
At 11:37 PM 3/9/2008, vlemaire.ext orange-ftgroup.com wrote:
Hello,
I'm currently analysing my network performances on streaming
applications over RDT/UDP. I observe a strange behaviour : sometimes the
throughput slows down, sometimes not. I really guess the data rate
reduction is due to RDT layer, probably because of bad performances of my
network, to investigate what causes this RDT reaction, I need the RDT
specification, but only RDT v2 and v3 features' description are available
on your web site. Do you know where and how could I get the RDT spec
V1.
Thanks
Best regards
Vincent
Rishi Mathew
Helix Community
Real
Networks, Inc.
rmathew real.com
http://www.helixcommunity.org
http://www.realnetworks.com/products/support/devsupport.html
_______________________________________________
Protocol-dev mailing list
Protocol-dev helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/protocol-dev
Rishi Mathew
Helix Community
Real
Networks, Inc.
rmathew real.com
http://www.helixcommunity.org
http://www.realnetworks.com/products/support/devsupport.html
|
[1]
|
|
|
about | contact Other archives ( Real Estate discussion Medical topics )
|