Subject: [MMUSIC] NOT encapsulating for media-loopback

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 2 Aug 2006 01:24:08 -0400

Hi again Kaynam, 
I'm not an RTP or qos-measurement expert, but I think I have an alternative
to encapsulation.  The only reasons I can think of you want to encap is so
the source can figure out 1-way jitter and which leg packet loss occurs in,
right?  So just have the source put the necessary info in the payload it
sends, which the mirror returns untouched.  Putting real codec media in the
payload has no value for pkt mode anyway, does it?  

So just have the source put its sequence number and timestamp into the
payload it sends, along with whatever padding/fill is necessary to make it
the right size for that codec payload.  The mirror generates/replaces its
own sequence number and receive timestamp in the real (and only) RTP header
it sends back.  

So if the source finds a missing sequence number generated by the mirror, it
knows a packet got lost from the mirror to it.  If it finds a missing
sequence number in the received payload without a corresponding missing one
generated by the mirror, it knows a packet got lost from the source to the
mirror.  At least that seems right to me.

The embedded timestamp just helps the source not have to do extra math or
store data to figure out when it sent the original packet.  It can compare
the received embedded time it originally sent with the received mirror's
timestamp for 1-way jitter.  The current draft says you need the mirror's
transmit timestamp as well, though.  I would argue it's ultimately always a
fixed offset of the received one, or close enough for jitter accuracy.  So
I'm not sure you actually need it to calculate return-path jitter. 

The benefits of the above are it's not much work for the mirror, so your
odds of getting devices to be mirrors increases; and I'm not even sure you
need to define the format or data put into the payload by the sender, as
long as you mandate the mirror copies the payload as opaque data.  So then
its only as much work for the source as it wants to do, and your odds of
getting devices to be sources increases.  (for example a simple phone as a
source can decide to just send media codec in the payload so a user can hear
their own voice and decide their own quality value)

-hadriel

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Colin Perkins <[email-masked]>
Date: Wed, 2 Aug 2006 10:33:59 +0100

On 2 Aug 2006, at 06:24, Hadriel Kaplan wrote:
> right?

That's one of the reasons I suggested this change. The other reason  
was to ensure the loopback stream conforms to the RTP specification,  
and can be congestion controlled if necessary.

Colin

---

From: Colin Perkins <[email-masked]>
Date: Wed, 2 Aug 2006 15:38:15 +0100

On 2 Aug 2006, at 15:07, Hadriel Kaplan wrote:
> But what I'm talking about does conform to RTP, at least as far as  
> anyone
> can tell.  Instead of encap'ing the whole received RTP packet, it just
> "encaps" the payload portion.  If you sniff the loopback stream, I  
> don't see
> how it looks any different from "real" RTP.
> The mirror can still generate RTCP and such.  I'm not following how  
> this is
> any less conforming to rfc3550 than the current draft-04.

I was explaining the effects of the changes in the -04 version of the  
media loopback draft, and made no comment on your proposal.

> I'm curious which type of congestion control you're referring to.   
> TFRC?
> DCCP?

Perhaps, although I was thinking more of plain RTCP reception reports.

> Correct me if I'm wrong, but don't those mechanisms employ congestion
> control based on loss?  Wouldn't the loopback source detect the  
> loss in both
> directions based on the algorithm in this draft and thus simply  
> control its
> transmission rate to match?  (granted it would have to take the  
> worst case
> congestion of both paths)

Yes, you could do that.  A better approach, which is made possible  
when the looped back packets are encapsulated into an RTP stream, is  
to monitor the congestion and jitter on forward and reverse paths  
independently, and adapt accordingly.

Colin

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 2 Aug 2006 10:07:16 -0400

But what I'm talking about does conform to RTP, at least as far as anyone
can tell.  Instead of encap'ing the whole received RTP packet, it just
"encaps" the payload portion.  If you sniff the loopback stream, I don't see
how it looks any different from "real" RTP.
The mirror can still generate RTCP and such.  I'm not following how this is
any less conforming to rfc3550 than the current draft-04.

I'm curious which type of congestion control you're referring to.  TFRC?
DCCP?  Correct me if I'm wrong, but don't those mechanisms employ congestion
control based on loss?  Wouldn't the loopback source detect the loss in both
directions based on the algorithm in this draft and thus simply control its
transmission rate to match?  (granted it would have to take the worst case
congestion of both paths)
I know I must be missing something basic. 

-hadriel

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: Wednesday, August 02, 2006 5:34 AM
> To: Hadriel Kaplan
> Cc: [email-masked]
> Subject: Re: [MMUSIC] NOT encapsulating for media-loopback
>

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 2 Aug 2006 16:05:34 -0400

Hi Colin,
I'm not clear why encapsulating the entire received RTP packet into the
mirror payload helps the mirror adapt for congestion any more than simply
copying the received payload into the mirror payload?  

Again, IANA rtp-expert, but I also wonder how having the mirror adapt to
congestion independently from the source is going to impact measurement
algorithms, for pkt-loopback mode.  For example, from my simple caveman
view: the source sends packets at 10ms ptime, and the mirror decides to
reduce its sending rate to 20ms ptimes due to congestion detection - it's
not real media so the mirror can't use an adaptive codec, so what does the
mirror do?  Does it encapsulate 2 received RTP packets into every 1 it
sends, or only send back half the received RTP packets?  Either way is bad,
no?

If you leave it up to the source to decide, I think it's far simpler.  With
the only-payload-copy mechanism, the source can detect congestion (loss) in
either direction, it can decide to react, and it can use/adjust whatever
measurement algorithm it wants to.

-hadriel

> Sent: Wednesday, August 02, 2006 10:38 AM
> To: Hadriel Kaplan
> Cc: [email-masked]

---

From: Colin Perkins <[email-masked]>
Date: Thu, 3 Aug 2006 00:27:36 +0100

> copying the received payload into the mirror payload?

It helps because you have both the outer RTP header, for the RTP  
stream from the mirror back to the source, plus the RTP header for  
the encapsulated packet. With both headers, you can tell where the  
congestion occurred (i.e. a gap in the outer sequence numbers is  
congestion on the reverse path, a gap in the inner sequence number is  
congestion on the forward path). If the congestion is only on the  
reverse path, you know there is no need for the source to reduce its  
rate.

> sends, or only send back half the received RTP packets?  Either way  

Most likely it only sends back half the packets, which reduces the  
accuracy of the measurement, but is safe for the network. The main  
thing for measurement is to "do no harm", surely?

> measurement algorithm it wants to.

It doesn't work though: the returned stream doesn't conform to the  
RTP specification, since there's a persistent SSRC collision, until  
the SSRC, sequence number and timestamp are rewritten, and  
appropriate RTCP generated. Once that's been done, you can't tell if  
there is congestion on the forward path, unless you encapsulate,  
which brings us back to something like the solution in media- 
loopback-04.

Colin

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Wed, 2 Aug 2006 21:47:22 -0400

> reverse path, you know there is no need for the source to reduce its

I think we may be mixing signals.  What I'm proposing, or maybe it's been
proposed before, is that for pkt-loopback mode the _source_ put a copy of
its timestamp and sequence number into the RTP payload it sends.  (e.g., in
place of media)  The mirror simply copies the RTP payload it receives into
an RTP packet it sends back.  So the mirror's RTP packets have the mirror's
timestamp and sequence number in the real (and only) RTP header.  

That way the source can tell where congestion occurred, using the same
mechanism you describe.  A gap in the received RTP sequence number is
congestion in reverse path, a gap in the payload's embedded sequence number
is congestion in the forward path.

The fundamental difference is IMO it's easier for the mirror.  At least from
my viewpoint copying just the payload is easier than encapsulating the whole
packet, fragmentation, etc.  Especially when one considers a poor-man's
mirror wouldn't really need to "copy" the payload to a new packet, but just
change some fields in the original and send it back out.  There's no MTU
issue, no packet size growth, etc.  

To me making the mirror operation as trivial as possible, doable in
hardware, etc., is vital; because you want a lot of mirrors out there.
I think it even makes the source function easier. 

> thing for measurement is to "do no harm", surely?

Totally, but the mirror only figures out it has congestion when it gets
RTCP, since RTP is not mirrored to it.  In that sense again there's no
difference between encapsulating and payload-copying.  

> which brings us back to something like the solution in media-

The mirror does re-write the sequence and timestamp of the RTP it sends -
with its own values.  That won't affect the source's seq and timestamp,
because their copies are safely inside the payload.  If using the same SSRC
is a big deal even for loopback, you can define the mirror change that too
in the draft, and have the source embed that in its payload as well if it's
of interest to it.

-hadriel

---

From: Colin Perkins <[email-masked]>
Date: Fri, 4 Aug 2006 11:30:33 +0100

Hadriel,

> issue, no packet size growth, etc.

The only benefit I see to this is that it avoids packet expansion on  
the reverse path. That can also be done in the encapsulation case, by  
just encapsulating the RTP header, rather than the complete packet.  
Note, however, that avoiding packet expansion does NOT avoid the need  
for fragmentation, since the reverse path MTU might be lower than  
that of the forward path.

> I think it even makes the source function easier.

I don't see any advantage in your proposal in terms of complexity.

> difference between encapsulating and payload-copying.

Sure.

> in the draft, and have the source embed that in its payload as well  

I don't understand why you think a copy of just the payload is easier  
than copying from the header into the payload?

Colin