Re: [payload] SDP O/A -- L, D, ToP and Flexible mode

[Varun Singh <[e-mail]>]

Hi folks,

The draft was reviewed and approved by the IESG, however, we have not
incorporated the feedback/comments raised by Bernard. Feedback on this
is appreciated, because it  changes the O/A mechanism of FlexFEC.

Regards,
Varun

On Tue, Mar 5, 2019 at 10:42 PM Varun Singh <[e-mail]> wrote:
>
> Hi,
>
> Forwarding my clarifications to Bernard’s review.
> Full email below.
>
> Feedback appreciated.
>
> Regards,
> Varun.
>
> ---------- Forwarded message ---------
> From: Varun Singh <[e-mail]>
> Date: Tue, 12 Feb 2019 at 5.40
> Subject: Re: SDP O/A -- L, D, ToP and Flexible mode
> To: Bernard Aboba <[e-mail]>
>
>
> Hi all,
>
> Thanks Bernard for the quick feedback. See my replies inline.
>
> On Mon, 11 Feb 2019 at 19.13, Bernard Aboba <[e-mail]> wrote:
>>
>> Comments below.
>>
>> On Feb 11, 2019, at 2:45 PM, Varun Singh <[e-mail]> wrote:
>>
>> Hi all,
>>
>> I  caught up on the mail discussion, initially, I did not run through all the cases, but Bernard's follow up email, makes me question if we have to be more specific.
>>
>> Everything in this email is scoped for the SDP.
>>
>> 0) IIRC the SDP for FlexFec was supposed to be declarative and not really a negotiation.
>>
>>
>> [BA] Is it only declaring in one direction - what to send, but not what it can receive? Or is there something implicit there?
>
>
> Yes. It’s only in one direction. The implicit assumption is that the endpoint can receive what it offers.
>
> I can think of an argument being made, where the Offers are what type of FEC protection/structure is willing to receive rather than send. However, the negotiation model would be rather complex (and the ability to announce several capability modes)
>
>
>
>>
>>
>> - Offerer supports FlexFEC, but the Answerer does not implement it, the Answerer would either reject the offer or remove flexFEC from the answer.
>>
>>
>> Otherwise, if both support FlexFEC, the Answerer would just send its own FlexFEC (L,D, ToP) configuration.
>>
>> I do not think negotiation makes a lot of sense:
>> For uni-directional media, offerer specifies L, D, ToP. Logically, the answerer cannot ask for higher values of L and D, or a different ToP. I think if the answerer disagrees in this case, it would just reject the offer or remove flexFEC from the answer.
>>
>>
>> [BA] Agree that negotiation isn’t a good model - but the asymmetry between Offerer and Answerer can create questions.
>>
>> What does an Offerer do if it receives an Answer with settings it does not support?  Is there a way for the Answerer to infer the set of settings an Offerer supports so as to make this unlikely?
>
>
> I don’t think there are really options in this case.
>
> If the offerer wants to use the interleaved mode, I don’t see a legitimate case for the answerer to try to figure out what other modes exist. In general I can’t see in what situation would negotiation help?
>
> Are you thinking of a situation where an offerer is not very opinionated at wants to describe that it’ instead lists a lot of L D ToP capabilities that the answerer then picks from?
>
>>
>>
>> For bi-directional media, the networks might behave differently, and thus, the endpoints may want to choose asymmetrical L and Ds. Which would mean that the Offerer and Answerer can have different L and D and O/A request and response is just telling the other party what their respective L and Ds will be?
>>
>>
>> [BA] Makes sense.
>>
>>
>> 1) The whole point of specifying L,D, and ToP (modes 0,1, and 2) in SDP was to have a rigid FEC transform structure. Agree or disagree?
>>
>>
>> [BA] Rigid structure makes sense if the goal is to maximize interop by specifying well known and required modes. But without required support for a set of configurations it can increase the complexity of negotiation. I do not like the idea of having to offer multiple potential flexfec configurations, for example.
>>
>>
>> 2) ToP and L/D modes
>>
>> - If an endpoint uses ToP 1 (non-interleaved), it must provide the number of columns (L)
>> - If an endpoint uses ToP 0 (interleaved), it must provide both L and D. L to know how much to skip and D to know which packets will be present.
>> - If an endpoint uses ToP 2 (2 Dimensional), since all packets in L and D are protected, it must provide L and D.
>> - If an endpoint wants to use the flexible FEC mode it must not specify L, D, or ToP.
>> (skipping retx for this now)
>>
>> Agree on these rules above?
>>
>>
>> [BA] Yes.
>
>
> I skipped RTX before. So if I understand some of the confusion and now I’m not sure what ToP 3 really means.
>
> Do ToP modes 0, 1, and 2 implicitly mean no RTX?
>
> If so, why do we have this following ambiguity  (L, D, ToP are all missing) means it is both Flexfec FEC and flexfec RTX?
>
>>
>>
>> I am assuming that L and D numbers in the SDP are exactly the ones that will be used in the protocol and the endpoints are not using the L and D values to mean anything between 0 to the specified value.
>>
>>
>> [BA] Is there an implicit indication of what the Offerer can deal with in an Answer (e.g. L and D values less than those in the Offer are supported in an Answer)?
>
>
> I think the implicit assumption is that all of  flex FEC spec is implemented.
>
> Offer can send and receive  X and answerer can send and receive Y.
>
> I can’t see why we would endorse a partial implementation?
>
>>
>>
>> 3) FlexFEC Retx and FlexFEC FEC
>>
>> - If an endpoint wants to use the flexible FEC and FlexFEC Retx it must not specify L, D, or ToP.
>>
>>
>> [BA] Makes sense - but what is required of a flexible mode receiver? Must it be able to decode anything a sender can send? If not, how does it tell the other side that it received something it could not decode?
>>
>> - If an endpoint wants to use only the FlexFEC Retx it will set ToP to 3 and skip L and D modes.
>>
>> Is there a way to specify FlexFEC and FlexFEC Retx?
>
>
> Should there be explicit way to say in SDP
>
> + flexfec FEC only
> + flexfec RTX only
> + flexfec FEC and RTX, both?
>
>>
>> If the endpoints are using a declarative modes, I dont think there is an issue here. There can be assymetry and if the other party does not like the Offer it can reject it or remove flexFEC from the answer.
>>
>> 4) FLEX FEC Retx and 4588 Retx =)
>>
>> The offer contains
>> FLEXFEC RTX and FEC along with 4588 RTX, i.e., no L,D,ToP for FlexFEC and 4588 retx
>>
>> The Answerer can remove the flexFEC line to indicate that it wants to use 4588 Retx, but thus it cannot have any form of flexFEC.
>>
>> Without a re-offer, I dont think the endpoints can do anything better.
>>
>>
>> [BA] Can we interpret negotiation of 4588 RTX to mean “no flexfec rtx, please”?
>
>
>
> Going with the declarative model and restrictions of the SDP o/a semantics (and I’m really suspicious about the validity of what I’m suggesting below)
>
> Case 1: everyone is happy
> Offerer declares rfc4588 RTX and flexfex (with Flex RTX) meaning it has complete flexibility in sending and receiving.
>
> Answerer responds with rfc4588 RTX and flexfec (without RTX, I don’t think we have a way of doing that), with this the answerer is declaring its restriction.
>
> Both parties in this case can figure out what needs to be done.
>
> Case 2: no RTX because no compatibility
>
> Offerer declares flexfec (with flex RTX), so no rfc4588 supported. Answerer can respond with flexfec (without RTX).
>
> In this case, while the offerer can send flex RTX the receiver won’t decode it (and answerer would anyway just discard these packets) So it can just assume not to send it. The answerer assuming didn’t want to send or receiv RTX would not send flex RTX.
>
>
>>
>>
>>
>>
>>
>> --
>> Founder, CEO, callstats.io
>> http://www.callstats.io
>>
>> Interested in networking, media quality, and diagnostics.
>> We are hiring!: www.callstats.io/jobs/
>
> --
> Founder, CEO, callstats.io
> http://www.callstats.io
>
> Interested in networking, media quality, and diagnostics.
> We are hiring!: www.callstats.io/jobs/
> --
> Founder, CEO, callstats.io
> http://www.callstats.io
>
> Interested in networking, media quality, and diagnostics.
> We are hiring!: www.callstats.io/jobs/



--
Founder, CEO, callstats.io
http://www.callstats.io

Interested in networking, media quality, and diagnostics.
We are hiring!: www.callstats.io/jobs/