Subject: [MMUSIC] RE: NOT encapsulating for media-loopback

From: "Hedayat, Kaynam" <[email-masked]>
Date: Wed, 2 Aug 2006 09:19:08 -0400

Hadriel,

You have raised very good points. However, the main reason behind
encapsulation of looped back media is enabling the mirror to follow the
rules of the RTP standard. As an example changing only a subset of RTP
header fields violates RTP (for example changing sequence number and
timestamp without modifying the payload violates RTP in situations where
payload has knowledge of the sequence numbers). Also without
encapsulation the mirror does not have any control over congestion.

Our goal has been a simple standard for straight forward implementation
of the media loopback. Our first attempt at the draft was very similar
to your suggestions. But the encapsulation method adds more flexibility,
follows the RTP standard, and provides more visibility into the path of
the call. 

The encapsulation on the surface looks like much added complexity. But
when you look into the details it is fairly simple. The mirror does not
touch the incoming packets, simply encapsulates it into another RTP
stream and loops back.

Regards,
Kaynam

> -----Original Message-----
> From: Hadriel Kaplan [mailto:[email-masked]] 
> Sent: Wednesday, August 02, 2006 1:24 AM
> To: [email-masked]
> Cc: Hedayat, Kaynam
> Subject: NOT encapsulating for media-loopback
> 
> 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: "Hadriel Kaplan" <[email-masked]>
Date: Thu, 3 Aug 2006 01:39:40 -0400

Hi Kaynam, comments inline...
(sorry about the length of this reply - email is not a good medium for this)

> From: Hedayat, Kaynam [mailto:[email-masked]]
> 
> payload has knowledge of the sequence numbers). 

So everyone's saying the mirror would violate RTP because the payload may
refer to the sequence number.  But the current draft takes the received RTP
packet and puts it in the outgoing payload.  How is the media changed?  And
it violates SDP because the mirror was offered media codec types and is not
sending them correctly - i.e., the mirror is setting a payload type which is
wrong for the profile.  And it may even be a layer violation since the
mirror generates RTP payload which should be passed from layer above, but
which is actually the entire received RTP packet which could not have passed
to that layer above to be handed back down.  Another example of this is the
last link to the mirror may be doing rfc2508 header compression, and so the
mirror would encapsulate only a partial header which the source has no clue
about. 
I would argue my way is less violating.  ;)

Of course I'm being facetious, because this is a new draft and can define
new mechanisms to solve a problem. (within reason)  Realistically the source
is no longer doing normal RTP, because it's receiving RTP from the mirror
with a payload type that it doesn't treat as such, with encapsulated RTP in
the payload, which it needs to do things with and not treat as media.  If
that's legitimate, then I'm at a loss why we're worried about the payload
*it generated* referring to sequence numbers, and sequence numbers which it
can embed right before that payload anyway.

> Also without

I keep hearing that and I don't understand it.  Nothing forces the mirror to
send.  Whether the mirror encapsulates received RTP or copies over the
received payload of that RTP won't change that fact.  In either case the
only data the mirror has at its disposal to discover it needs to backoff is
RTCP, no?  I am NOT suggesting it not generate and receive RTCP, if it can. 

Regardless of whether the mirror encaps or copies, some measurements will be
wrong if the mirror backs off due to congestion.  In that sense I think it
makes more sense to have the source back off, even if the congestion is only
in the reverse direction; and the source will know that info using either
mechanism.  But that source-behavior doesn't need to be mandated in a draft
at all - it doesn't impact interoperability.

> follows the RTP standard, and provides more visibility into the path of

I'm also looking for a simple implementation of a mirror, because I think
it's the key to making this broadly applicable and implemented.  So to me,
that would mean simple to do in software and/or hardware.  Hardware
obviously comes in many flavors, but in my experience encapsulation is
harder to do than overwriting fixed length words at fixed offsets, where
"harder" means more instructions, more memory, or more cycles.  It's not
harder for my particular products I think, but I'm trying not to constrain
it.  The fact that the encapsulated packet may need to be striped across 2
RTP mirror packets also makes it harder for hardware.  IMO, all the heavy
work should be done by the source.

In terms of flexibility, nothing to me is more flexible than letting the
source decide what data it wants to be mirrored back, by having it embed
that data in the payload it sends.  If it cares about sequence numbers,
timestamps, and ssrc then it embeds them in the payload it sends.  If it
only wants to stream a PESQ file, then it sends that.  If it wants both then
it does both.  If it only wants to act like a phone and send user g.711
media so the user can hear herself talk, it can do that without any changes
other than SDP.  What's more flexible?

-hadriel

---

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

On 3 Aug 2006, at 06:39, Hadriel Kaplan wrote:
> wrong for the profile.

This shouldn't violate SDP: the offer/answer exchange negotiates the  
encapsulating payload format in the same way any other codec is  
negotiated. If that isn't done, the draft needs to be fixed.

> And it may even be a layer violation since the
> to that layer above to be handed back down.

Why is this a layering violation? There is nothing in the RTP  
specification that requires only audio/visual media be used, nor  
requires a layered implementation. Indeed, RFC 3550 specifically  
calls out measurement applications as a reasonable use case, and  
discourages layered implementations, in Section 1.

> Another example of this is the

RTP header compression is invisible to this format, since the headers  
will be logically regenerated before they're made available to the  
application. I don't see how this can be an issue.

> can embed right before that payload anyway.

Why would that not be legitimate? RTP is not limited to audio/visual  
media. This is real-time data, and so can be transported by the real- 
time transport protocol. You seem to have a particular model for an  
RTP end point that, while typical, is not the only allowable use for  
the RTP protocol.

> send.

In the -03 draft, the sender looped back packets without regenerating  
a new RTP header. That made it impossible to perform congestion  
control on the reverse path, since there was no feedback on loss.  
Both the -04 draft, and your proposal, allow congestion control of  
the reverse path.

> Whether the mirror encapsulates received RTP or copies over the

Correct.

> at all - it doesn't impact interoperability.

Agreed.

> work should be done by the source.

Your proposal does not eliminate the need for fragmentation, it  
merely reduces the likelihood of it occurring. The same thing could  
be done by only encapsulating the RTP header on the reverse path,  
rather than the complete payload. In all cases, though, the mirror  
will need to be aware of potential fragmentation, since the MTU on  
the reverse path may be lower than on the forward path.

Colin

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 4 Aug 2006 19:34:22 -0400

> From: Colin Perkins [mailto:[email-masked]]
> 

I asked Kaynam about it and he pointed out something which I totally missed
- they're using a different payload type for the encapsulated flow.  If so I
apologize for the misunderstanding and take back that comment.  I had
assumed they were using the same PT in both directions.  Since it's a unique
PT/profile for the encaprtp side, I would say a unique PT/profile would also
be used if the payload were copied instead of encap'ed.  

Having said that, I will say I'm not sure it's going to work right in some
environments.  Some packet-forwarding middle boxes look at the offer/answer
and create expedited and policed queues based on it, remove
unknown/disallowed payload types, etc.  (and I'm not just talking about
SBCs)  I worry that the measurement of the mirrored flow may be wrong
because of this, or may be blocked, or whatever.  Even if the UA's use RSVP
or some such to setup QoS, they have to account for the encap growth, and it
won't be the same as real session would have used.

IMO, if you want to measure what a given media session would be like, you
should make it look as much like that media as possible.  I know setting the
same PT as a defined profile and not doing that profile in the payload is
against IETF policy, but it's the best engineering solution to solve the
problem at hand, IMHO.  
Just my 2 cents.

> discourages layered implementations, in Section 1.

There's no doubt it's not treated as a layer by all of its profiles, but I
don't see how that helps the encapsulation scheme any.  The packets sent
from the source to the mirror can still be set to payload types of
well-defined profiles, right?  So how could that well-defined
RTP-integrated-application on the mirror receive an RTP packet and hand it
entirely to the sending application which is encaprtp? 

(I know this is getting pedantic, but to me the idea that a mirror who
understands this draft can't copy over just the payload to the sending side,
and a source who offered this draft can't know what he's sending, is
bizarre)

> RTP end point that, while typical, is not the only allowable use for

Sorry, see my note before - I thought the draft intended to use the same PT
for both flows, including the encap one.

> the reverse path may be lower than on the forward path.

I totally agree.  And even if doing a payload mirror approach, the draft
would have to mandate such be handled.   

However, I would assert that's not the real world.  Since fragmented UDP has
real problems getting through home NATs and some firewalls, I find
implementers are very careful not to make RTP bigger.  Even some routers out
there do ECMP and Link-aggregation distribution based on hashing
address+port, and the not-first fragments end up going a different path.  If
encapsulation puts it over the top, it won't behave the same as the real RTP
session for measurements, and it won't work through a home NAT/firewall.  
I wouldn't even care about this issue really, except some RTP applications
do hit the common 1500B MTU.  

-hadriel

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 4 Aug 2006 20:25:42 -0400

> If

Strike that bit - I forgot the current encap scheme has it stripe over
multiple RTP packets.  That'll obviously get through a NAT.  I do still care
about the MTU issue - I would like to keep probability of exceeding it as
low as possible, by not increasing the size in the reverse direction.  

-hadriel

---

From: Colin Perkins <[email-masked]>
Date: Sun, 6 Aug 2006 10:25:46 +0100

> against IETF policy, but it's the best engineering solution to  

Breaking the architecture due to buggy implementations doesn't seem a  
good trade off to me.

> well-defined profiles, right?

[You seem to be confusing Payload Formats and Profiles; I assume you  
mean payload formats here]

> So how could that well-defined

I don't understand this comment at all.

> do hit the common 1500B MTU.

So just encapsulate the RTP header on the return path, ignoring the  
payload (the source knows the contents of the packets it just sent,  
so having the mirror send them back is a waste of bandwidth; all you  
need is the timing of when they arrived, which an encapsulating  
payload format is well suited for).

Colin

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 7 Aug 2006 11:11:55 -0400

> I don't understand this comment at all.

I think the argument used against payload copying is it doesn't comply with
RFC 3550, and that some media payloads reference the sequence number.  I
assume the sender source know fairly well what it's sending, so it knows the
media payload it uses.  I believe I have addressed any inconsistency with
3550, since the mirror generates its own RTP headers, including seq,
timestamp, ssrc, PT, etc.  In effect it looks exactly like the encap model
except instead of encapsulating or copying received RTP header, it simply
copies the received payload.  

The next problem with it would be that the source would be sending a PT
which does not match what it put into the payload, if it put things like
seq/timestamp in there but used a well-defined PT.  I assume that would not
be acceptable in the IETF, even though the source and mirror are in
agreement about doing this.  Right?

> payload format is well suited for).

Would this behavior need to be specified as an SDP negotiated mirror
pkt-loopback mechanism in the draft, or are you saying if the mirror
accepted pkt-loopback mode it could choose whether to just copy the RTP
header vs. encap the whole received RTP? (i.e., will the source know ahead
of time which it is?)

I can think of a need to return the received payload as well: if a user
phone wants to make such a test, and let the user hear herself.  Obviously
that can be done with media-loopback mode as well, but doing it in
pkt-loopback lets the phone also display the one-way jitter and loss during
the call.  The encapsulate method works for that too, but the payload copy
method means the source can choose how clever it wants to be, and not
consume DSP resources or even have a DSP on the mirror.

Maybe we could offer both?  I.e., offer a payload-loopback option as well as
pkt-loopback and media-loopback options?  The payload-loopback would NOT
specify that the source put in anything other than the right payload for the
PT it sends - so if it wants to stick its seq/timestamp in the payload it
must use a dynamic PT for that by putting it in its loopback-source
attribute line.

-hadriel

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 8 Aug 2006 09:49:50 -0400

You could have a third mode which either copied enough of the received
packet to make it the same size as it would if it were the original packet,
or maybe better, just pad with random data to that size.   That would let
you get return packets that were smaller, same size, or larger than the
original. 

Brian

> Sent: Monday, August 07, 2006 11:12 AM
> To: 'Colin Perkins'
> Cc: [email-masked]
> Subject: RE: [MMUSIC] RE: NOT encapsulating for media-loopback
> 
> 
>

---

From: Colin Perkins <[email-masked]>
Date: Tue, 8 Aug 2006 21:37:52 +0100

> copies the received payload.

Right: you save 12 octets in the usual case, but lose the ability to  
tell where the congestion was happening.

> agreement about doing this.  Right?

The signalling needs to match the contents of the media stream, clearly.

> header vs. encap the whole received RTP? (i.e., will the source  

It would need to be signalled. Whether that's done in the SDP, or by  
a bit in the encapsulating payload header is a design choice which I  
have no particular opinion on.

> must use a dynamic PT for that by putting it in its loopback-source

If you can convince the authors it's a good idea, and if you document  
the payload formats you use in both directions, and ensure the result  
conforms to RTP and the SDP offer/answer model, then I have no  
objection (although I don't see it offers any benefit, other than  
saving 12 octets per encapsulated packet).

Colin