Subject: RE: Clarifications on [AVT] Sequence issue withdraft-ietf-avt-rtp-selret-04.txt

From: Bill Foster <[email-masked]>
Date: Fri, 21 Jun 2002 17:38:11 -0700

>
>So it seems legimitate to think that if you need two sequence number 
>spaces, a simpler solution would be to send the original packets and the 
>retransmitted packets into two separate RTP streams.

Not really. Unfortunately, having two separate RTP streams is more of a 
problem for some applications than the problem it is trying to solve. If 
the retransmissions are sent in a separate RTP stream, there is no 
indicator that the retransmitted packet was lost.

draft-ietf-avt-rtp-selret... solves that problem by treating handling all 
lost packets in the same way. This same characteristic that some may not 
like (the fact that you can't differentiate lost RTP packets from lost 
retransmitted packets) is in fact the same feature that some think is 
important (maybe you could say that one application's feature is another 
application's bug).

Also an RTX format where headers accumulative (along with the approach of 
using the same sequence number space) is important for some applications. 
For example, with draft-ietf-avt-rtp-retransmission-01.txt, if the sequence 
number wraps before I get a chance to get the retransmitted packet through, 
I've lost the opportunity to retransmit the packet. 
draft-ietf-avt-rtp-selret maintains a history, so that even if a wrap 
occurs, the opportunity to retransmit has not gone away.

The approach in draft-ietf-avt-rtp-selret has some distinct advantages over 
draft-ietf-avt-rtp-retransmission-01.txt for some applications. I would 
hate to see those advantages get lost with an attempt at a 
one-size-fits-all approach.
-----------------------------
Bill Foster
Phone: (250) 758-9418
Fax:     (781) 998-6492

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

---

From: [email-masked]
Date: Tue, 25 Jun 2002 11:37:19 -0500

Bill,

[David]
> >retransmitted packets into two separate RTP streams.

[Bill]
> indicator that the retransmitted packet was lost.

[David]
Bill, first of all please be aware that my text above was referring to Jose's proposal of defining an RTP encapsulation payload format which woud be used to carry all the data the user is sending plus a counter, i.e. having two sequence numbers per packets. I personally find it hard to be convinced that this encapsulation format is a good idea for solving reliable user data loss detection.
You're making the point that there is no indication that a retransmitted packet is lost if you're using two separate RTP streams. In this case, the indication of packet loss is simply that the retransmitted packet was not received.
Futhermore, if you are concerned with the loss of a retransmission packet, it seems to me that you should be equally concerned with the loss of packet retransmission request sent by the receiver to the sender. Please bear in mind that if you are using the selret draft you will not be able to detect the loss of a request packet and as a consequence multiple retransmission will fail.  

[Bill]
> important (maybe you could say that one application's feature 

[David]
Again, my comment was on the proposal to define a new RTP encapsulation format in order to be able to differentiate packet loss at the receiver. 

[Bill]
> occurs, the opportunity to retransmit has not gone away.

[David]
I'm trying to figure out the scenario you have in mind. Please let me know if I misunderstood something.

First of all, you are expecting to see the whole range of RTP SN (2 bytes) being sent in the order of the round trip time. This means that you have an application with extremely high packet rate and bitrate, at least several megabits per second. At the same time you have a high packet loss rate if you expect a packet and its retransmission to be lost. Shouldn't you react to congestion and send at a lower rate?

I'm also wondering about the type of buffering your application would require.
In the case that you are contemplating, the receiver is buffering *all* the RTP packets sent by the sender during at least the whole SN range (65536 packets). At the sender, you would have to buffer a multiple of this, in order to perform retransmission over multiple SN rollover. If you are using such buffering, I'm wondering if RTP is the right transport protocol for your needs.

Please also refer to my comments above related to multiple retransmission and detection of a lost retransmission request.    

[Bill]
> one-size-fits-all approach.

[David]
You shouldn't worry about that since that the WG decided to have two drafts which may evolve separately. Discussing the applicability of these drafts is I think beneficial to everyone and your contribution is greatly appreciated. I believe it would help if you could clarify the type of application you have in mind and what you see as the distinct advantages of selret. 

Thanks, David.