Subject: RE: [AVT] IESG comments on draft-ietf-avr-rtp-retransmission-11.txt - Issue 5: multiple retransmission requests

From: "Jose Rey" <[email-masked]>
Date: Wed, 22 Jun 2005 17:36:09 +0200

> -----Original Message-----
> From: W. Mark Townsley [mailto:[email-masked]] 
> Sent: Wednesday, June 22, 2005 4:38 PM
> To: Jose Rey
> Cc: TSV ADs; Magnus Westerlund; Colin Perkins; 
> [email-masked]; IETF AVT WG
> Subject: Re: [AVT] IESG comments on 
> draft-ietf-avr-rtp-retransmission-11.txt - Issue 5: multiple 
> retransmission requests
> 
> 
> 
> Jose Rey wrote:
> 
> > Mark,
> > 
> > "Page 13, Section 7, Congestion control.
> > 
> > 
> >>   In addition, the sender MAY selectively retransmit only the 
> >>   packets that it deems important and ignore NACK messages 
> for other 
> >>   packets in order to limit the bitrate.  
> > 
> > 
> > I think this could end up creating a situation where one 
> side asks for 
> > a packet repeatedly (multiple retransmission NACKs), and the other 
> > side ignores the request repeatedly (not sending due to selective 
> > retransmission)? Is this considered a reasonable and 
> expected behavior 
> > of the protocol?"
> > 
> > ==>Yes, but this is not dangerous. A client may report over a fixed 
> > window of SN values, in other words, carry fixed number of 
> RTCP NACK 
> > reports as the RTCP packet size allows.  Although this 
> > client-requesting-server-ignoring can happen a couple of times it 
> > doesn't add any danger or overhead since the NACK window 
> simply "moves 
> > on"
> 
> So, I assume the max receive window size is defined to be 
> smaller than the min number of retransmissions?
> 

I don't think so...I don't understand why you draw this conclusion ? 

Say min no. rtx is 2. If the "window" is 10, that means that the client just reports in each RTCP packet for all missed SN from the current to the previous 10 packets, SN-10. If when trying to include a SN in the RTCP rtx request the packet is out of the window, it is simply ignored.  That would happen when the current SN=50 and we want to request 2 retransmission for SN=39, for example

José

> - Mark
> 
> > 
> > Cheers,
> > 
> > ---------------------------------------------
> > Jose Rey     mailto:[email-masked]
> > P R D C G - Panasonic R&D Center Germany GmbH
> > Phone/Fax: +49(0)6103766-134/166
> > ---------------------------------------------
> > 
> > 
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/avt
> > 
> 
> 

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: "W. Mark Townsley" <[email-masked]>
Date: Sun, 26 Jun 2005 06:40:49 -0400

Jose Rey wrote:

> 
> 
> 
>> -----Original Message----- From: W. Mark Townsley
>> [mailto:[email-masked]] Sent: Wednesday, June 22, 2005 4:38 PM To: Jose
>> Rey Cc: TSV ADs; Magnus Westerlund; Colin Perkins; [email-masked];
>> IETF AVT WG Subject: Re: [AVT] IESG comments on 
>> draft-ietf-avr-rtp-retransmission-11.txt - Issue 5: multiple retransmission
>> requests
>> 
>> 
>> 
>> Jose Rey wrote:
>> 
>> 
>>> Mark,
>>> 
>>>> In addition, the sender MAY selectively retransmit only the packets
>>>> that it deems important and ignore NACK messages
>> 
>> for other
>> 
>>> a packet repeatedly (multiple retransmission NACKs), and the other side
>>> ignores the request repeatedly (not sending due to selective 
>>> client-requesting-server-ignoring can happen a couple of times it doesn't
>>> add any danger or overhead since the NACK window
>> 
>> simply "moves
>> 
>>> on"
>> 
>> So, I assume the max receive window size is defined to be smaller than the
>> min number of retransmissions?
>> 
> 
> 
> Say min no. rtx is 2. If the "window" is 10, that means that the client just
> reports in each RTCP packet for all missed SN from the current to the
> previous 10 packets, SN-10. If when trying to include a SN in the RTCP rtx
> request the packet is out of the window, it is simply ignored.  That would
> happen when the current SN=50 and we want to request 2 retransmission for
> SN=39, for example

OK, I was misinterpreting what the "window" was here.

My concern, in general, with this document is that with so many value being left 
"up to the implementation" or that are "dependent on the application" that there 
may be deadlock situations if one side chooses a very different value for its 
implementation than the other. In general, the more flexibility you give the 
implementor, the larger your test matrix must be, and the more possibility there 
is to run into problem situations no one ever dreamed of.

This particular case I was picking on at least sounds recoverable.

- Mark

> 
> José
> 
> 
> 
> 
>> - Mark
>> 
>> 
>>> Cheers,
>>> 
>>> --------------------------------------------- Jose Rey
>>> mailto:[email-masked] P R D C G - Panasonic R&D Center Germany
>>> GmbH Phone/Fax: +49(0)6103766-134/166 
>>> _______________________________________________ Audio/Video Transport
>>> Working Group [email-masked] https://www1.ietf.org/mailman/listinfo/avt
>>> 
>> 
>> 
>