Subject: Re: Raising the bar on the MBone

From: Petri Helenius <[email-masked]>
Date: Sat, 9 Aug 1997 11:07:05 +0300 (EEST)

At 12:43 7.8.1997 -0400, Brian O'Shea wrote:
>
>-
>-At 14:04 6.8.1997 -0400, Brian O'Shea wrote:
>->-At 09:46 6.8.1997 -0400, Brian O'Shea wrote:
>->->
>->->This of course would be much easier for us to do if RTP had included a
start
>->->of frame bit along with the end of frame bit...  Sigh....
>->->
>->-You only would need one of these, not both.
>->
>->Great!  
>->
>->Could you clue me in as to how I can tell when I've got a set of RTP video
>->packets that comprise a complete frame just by using the RTP header info?
>->
>-Unfortunately I don't have the RTP spec handy and will not have it for
>-another 3-4 days until I arrive to IETF. (since cellular data costs in
>-France are kind of high because of state monopoly, though getting better)
>-
>-However, at that time, I can look at the spec (which, obviously you can do
>-yourself) but I'm not sure whether I indicated such bit exists, but if you
>-are into putting a bit like that in there, you'll not need _TWO_ bits but
>-only _ONE_.
>
>Ahh, I think we're saying the same thing, just not understanding each other. 
>You need 2 bits, one for the start of frame, and one for end of frame.  Since
>there is already a bit for end of frame, you are right, I only need one more.
>
NO. You need one bit. The one that, according to your quote, is already there.

>There is a mechanism described in the RTP spec whereby you can use some of the
>bits from payload type if you want, but it's not strictly "standard".
>
>>From RFC 1889:
>	
>marker (M): 1 bit
>        The interpretation of the marker is defined by a profile. It is
>        intended to allow significant events such as frame boundaries to
>        be marked in the packet stream. A profile may define additional
>        marker bits or specify that there is no marker bit by changing
>        the number of bits in the payload type field (see Section 5.3).
>
>
>The problem is that you want it to be standard so that EVERYONES intelligent
>router/kernel/switch/other network box can identify a complete frame, and
>throw packets away appropriately.
>
Yes. So the one bit there needs to be further defined, like it's always set
at the last packet of the data unit (frame in the case we´re discussing).
This would allow an intelligent gateway to drop all packets belonging to a
data unit.

Pete

---

From: Karl Auerbach <[email-masked]>
Date: Sat, 9 Aug 1997 10:18:23 -0700 (PDT)

> This would allow an intelligent gateway to drop all packets belonging to a

There are many existance proofs that the current (one-bit) mechanism works
just fine, even with the M bit being used in some cases to indicate the
*start* of a talk spurt and in others to indicate the *end* of a video
frame. 

You do have to know the profile and payload definitions and dynamic
mappings for the packets you are carrying.  The former part of this you
get by reading the RFCs and internet drafts, the latter by listening to
SD* announcements.

I'm wondering how, for audio, one would use an "end" bit.  If you wanted
to mark the *end* of a talk spurt, you'd end up having to delay outgoing
audio in order to know whether it was the last packet of the spurt.

Moreover, in the case of a "reflector" that wants to drop frames, the
"reflector" is going to have to handle out of order and duplicated
packets, so the work needed to do proper M bit evaluation is not going to
add an additional burden. 

		--karl--