Subject: RE: [AVT] Re: Working group last call: draft-ietf-avt-evrc-smv-00.txt

From: Pete McCann <[email-masked]>
Date: Tue, 30 Apr 2002 23:00:20 -0500 (CDT)

Hi, Stephen,

Stephen Casner writes:
 > This is an explanation why forcing the implementation to support type
 > 1 "is not too bad", but it doesn't tell me why the requirement should
 > be imposed.  As the guidance in RFC 2119 says, "MUST" should be used
 > only where it is required for interoperation or to limit behavior
 > which has the potential for causing harm.

Would you be satisfied with a draft that gave both alternatives, and
then required at least one to be implemented?  Some of your comments
seemed to imply splitting the draft in two.  I hope we don't have to
do that.

Another option would be to make one format a MUST and the other a
MAY.  Is that what you had in mind?

 > > In the EVRC/SMV draft, we originally
 > > used the first bit to distinguish the long header for interleaving and short
 > > header for non-interleaving. In order to achieve zero-header (which together
 > > with header compression will work well with the wireless links), we move
 > > that signal to the ptype in MIME. This is not too far a deviation of the
 > > same idea.

 > But I don't think there is any motivation to switch between these
 > modes in one conversation.  For some applications minimum latency is
 > critical, so the zero-overhead mode is used.  For others, latency is
 > less a concern and bundling/interleaving can reduce packet load and/or
 > improve error resilience.  Therefore, I think signaling out-of-band is
 > the right choice independent of any zero-header considerations.

I agree, I also don't see much need for switching between formats in-band.

 > > That's the history and reason of how the draft comes to it is
 > > now, as far as I know. Any suggestions on what should we do?
 > 
 > I stated what I thought should be done.  I'd like to hear from others.

I would support relaxing the MUST into either "at least one" or a
MUST+MAY.  However, I don't want to see the draft split in two.

-Pete

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

---

From: Stephen Casner <[email-masked]>
Date: Wed, 1 May 2002 23:51:42 -0700 (PDT)

> seemed to imply splitting the draft in two.  I hope we don't have to

No, it was not my intention that the draft should be rewritten or
split in two.

> MAY.  Is that what you had in mind?

Not exactly, because that means the guy who wants to use only the
"MAY" format would still have to implement both to be compliant.  I
believe it would be acceptable for the specification to say that both
formats SHOULD be implemented to maximize interoperability.  My
objection is to the statement that receivers MUST implement both.

Then, because implementations may need to decide on accepting an SDP
offer based on which of the two formats is proposed, the two formats
should be identified by separate MIME subtypes rather than by a
parameter of a single subtype.

							-- Steve

---

From: "Adam Li" <[email-masked]>
Date: Fri, 3 May 2002 00:05:19 -0700

> parameter of a single subtype.

Hi Steve,

I do see very well your concerns on this issue.

(1) It does seem a little bit awkward to require that both format must be
supported when the wireless nodes will probably always use only one of them.

However, I am not sure changing that word to "SHOULD" is going to either
make it look much better or eliminate the interoperability problem
completely. Probably it achieves neither goal. Take for example (sorry for
another example :-)), I guess the authors of RTP RFC are probably regreting
that maybe they should put a "MUST" in that RFC for RTCP instead of a
"SHOULD". The RTCP issue has constantly come up on this reflector. Changing
the "SHOULD" to "MUST" for RTCP now will create much trouble for the
existing implementations, but I am guessing the authors' and many people
here probably incline toward a "MUST" indeed. "Implementing some basic RTCP
is not that hard after all, right?" I heard people argue.

All it takes to add Type 1 support on top of Type 2 support (or vice versa)
for EVRC/SMV is to skipping a two octet header. "ptr += 2". My opinion is
that is a very small price to pay compare to the potential trouble and the
potential regret in the future. Just my personal opinion though, and I am
open to hear all suggestions on this. If a "SHOULD" is what people thinks it
should be, I am allright with it.

(2) About whether the type should be indicated by MIME subtype or a
parameter, I am not sure about that either. So, are we going to have two
MIME subtype - EVRC1 and EVRC2?

That seems to complicate the negotiation process quite a bit. Now two
seperate sets of parameter can be exchanged. Even after two terminals agree
on one, there could be another more efficient setup. Also, there is still
such probablity that two terminals will not talk to each other, even they
speak the same codec and using the same RFC. The storage mode of the two
subtype are exactly the same, but an implementation will have to register
itself twice for both types. Besides, it seems there is no precedent of this
type of double subtype before for all the payload types here.

Things seem to be so much simpler if we have the "MUST" and a single
subtype. Each terminal announces once and there is no guess work on what the
other side can do. And the cost for that seems to be quite minimal. Again,
this is just my personal opinion, and I am very open to further discussions.

Adam

---

From: Stephen Casner <[email-masked]>
Date: Tue, 7 May 2002 16:12:41 -0700 (PDT)

Adam,

> completely.

I agree, it does not eliminate the interoperability problem.  But I
also believe it does not make the problem worse.  The interoperability
problem stems from the fact that all parties concerned could not agree
on a single format for all uses.  Hence, there are two formats and the
possibility/probability that some implementations will support only
the one that is appropriate for their perceived application
environment.  This will be true whether the draft says MUST or
SHOULD.

> Probably it achieves neither goal. Take for example (sorry for

The revision of the RTP RFC does _not_ change from SHOULD to MUST
precisely because it would not be appropriate to increase the
requirement level for existing applications, and because there are
applications in which sending RTCP (from all receivers) is infeasible
or impossible.

But this example is not relevant to the question for the EVRC/SMV
draft because 1) draft is not published yet, and 2) we're talking
about changing MUST to SHOULD.

> potential regret in the future.

That is why I say SHOULD, not MAY.  But for an implementation in an
environment where only one of the formats is feasible, e.g., if
zero-byte header compression must be used, then it is not reasonable
for the spec to say the implementation MUST include both as it does
not meet the constrainst of RFC 2119 for that term.

> Just my personal opinion though, and I am open to hear all
> suggestions on this. If a "SHOULD" is what people thinks it should
> be, I am allright with it.

I would like to hear other opinions beyond mine and the authors'.

> seperate sets of parameter can be exchanged.

I disagree.  Two sets of parameters must be exchanged in either case
because the payload type must be bound to a particular format type:

     a = rtpmap:97 EVRC    \            /    a = rtpmap:97 EVRC1
     a = fmtp:97 ptype=1    \          /
                             >  -OR-  <
     a = rtpmap:98 EVRC     /          \     a = rtpmap:98 EVRC2
     a = fmtp:98 ptype=2   /            \

> Even after two terminals agree on one, there could be another more
> efficient setup.

I don't know what this means.

> Also, there is still such probablity that two terminals will not
> talk to each other, even they speak the same codec and using the
> same RFC.

I agree.  I addressed the root of that problem above.

> The storage mode of the two subtype are exactly the same, but an
> implementation will have to register itself twice for both types.

No, the storage mode should be registered for only one of the types.
Since the storage mode has a TOC byte, I would say it makes most sense
for this to go with type 1.  The other registration would be for RTP
transport only.

I would not use "EVRC1" and "EVRC2".  I think "EVRC" is the right name
for type 1 and for storage.  The type 2 could be EVRC-ZERO or EVRC0 or
whatever you (authors) decide is appropriate.

> Besides, it seems there is no precedent of this type of double
> subtype before for all the payload types here.

RFC 2250 is the precedent:  MPA + MPV, or MP1S, MP2T, MP2P.

> this is just my personal opinion, and I am very open to further discussions.

It would be even simpler with only one format.

							-- Steve

---

From: Colin Perkins <[email-masked]>
Date: Wed, 08 May 2002 10:45:35 +0100

Adam,

>environment.  This will be true whether the draft says MUST or
...
>I would like to hear other opinions beyond mine and the authors'.

I largely agree with Steve on this issue. The MUST -> SHOULD change is to
reflect the reality that there will be non-interoperable implementations,
since there are some scenarios where one format doesn't make sense.

The trade-off is between optimizing the formats for particular uses and
maximizing interoperability. This draft choses the former: if that's not
an appropriate tradeoff, we should rethink the payload format design. If
it is appropriate, the draft should recognize the interoperability issue.

Colin