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

From: Bernard Aboba <[email-masked]>
Date: Tue, 5 Mar 2019 12:20:13 -0800

Varun --

Have your suggestions for clarifying the SDP O/A answer negotiation in the
document made it into the updates to draft-ietf-payload-flexible-fec-scheme?

I re-read the latest update, and the problems still seem like they remain.

On Tue, Feb 12, 2019 at 3:09 PM Bernard Aboba <Bernard.Aboba=
[email-masked]> wrote:

> On Feb 12, 2019, at 2:12 PM, Varun Singh <[email-masked]> wrote:
> >
> > Do ToP modes 0, 1, and 2 implicitly mean no RTX?
>
> [BA] I believe that is what is implicit now, though it doesn’t make much
> sense to me.
>
> > If so, why do we have this following ambiguity  (L, D, ToP are all
> missing) means it is both Flexfec FEC and flexfec RTX?
>
> [BA] Good question. For me, flexible versus fixed and rtx/no rtx are
> orthogonal questions.
>
> > 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?
>
> [BA] I agree that all major features and bitmask sizes should be mandatory
> to implement. Would also like to see requirements on supported L and D
> values. With this clarified the declarative model would work much better.
> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload
>

---

From: Varun Singh <[email-masked]>
Date: Tue, 5 Mar 2019 22:23:04 +0200

Hi Bernard,

Thanks for following up.

I didn’t get much feedback apart from you on the proposal, so I’d
appreciate if others could weigh in on the suggestions.

Regards,
Varun.

On Tue, 5 Mar 2019 at 22.20, Bernard Aboba <[email-masked]> wrote:

>> [BA] I agree that all major features and bitmask sizes should be
>> mandatory to implement. Would also like to see requirements on supported L
>> and D values. With this clarified the declarative model would work much
>> better.
>>
> --
Founder, CEO, callstats.io
http://www.callstats.io

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

---

From: Varun Singh <[email-masked]>
Date: Tue, 5 Mar 2019 22:42:45 +0200

Hi,

Forwarding my clarifications to Bernard’s review.
Full email below.

Feedback appreciated.

Regards,
Varun.

---------- Forwarded message ---------
From: Varun Singh <[email-masked]>
Date: Tue, 12 Feb 2019 at 5.40
Subject: Re: SDP O/A -- L, D, ToP and Flexible mode
To: Bernard Aboba <[email-masked]>

Hi all,

Thanks Bernard for the quick feedback. See my replies inline.

On Mon, 11 Feb 2019 at 19.13, Bernard Aboba <[email-masked]>
wrote:

> Comments below.
>
> On Feb 11, 2019, at 2:45 PM, Varun Singh <[email-masked]> 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.

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)?
>

>
> 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.

> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcallstats.io&data=02%7C01%7CBernard.Aboba%40microsoft.com%7C3fffe8653f2c43d5ba9008d690728e79%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636855219033517244&sdata=ZdhqR%2Bp9ZTHzh8rtWWX%2BABFdI9VOUcvqZe6bVQayHAE%3D&reserved=0>
> http://www.callstats.io
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.callstats.io&data=02%7C01%7CBernard.Aboba%40microsoft.com%7C3fffe8653f2c43d5ba9008d690728e79%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636855219033522227&sdata=f0fQdqrC6DeRzINnawlYBiyYkYhHyDjIrGU9qoIiajQ%3D&reserved=0>
>
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.callstats.io%2Fjobs%2F&data=02%7C01%7CBernard.Aboba%40microsoft.com%7C3fffe8653f2c43d5ba9008d690728e79%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636855219033527217&sdata=bVvssFGzri2akZm7aPiDJ%2BLLggFcrbRkg32BI%2FTO4IY%3D&reserved=0>
>
> --

---

From: Varun Singh <[email-masked]>
Date: Thu, 21 Mar 2019 17:45:25 +0200

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 <[email-masked]> wrote:
> On Mon, 11 Feb 2019 at 19.13, Bernard Aboba <[email-masked]> wrote:
>>
>> Comments below.
>>
>> 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.
>>
>> 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.
>>
>> 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?
>
>
> 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.
>> 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.
>
> 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.
>
>> - 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?
>
>
>> 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.
>>
>> 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.
>>
>> [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)
>
> 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.
>
> 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.
>
>
>>
>>
>>
>>
>>
>> --