Re: [Simple] What ACM is all about [was: RE: MSRP-ACM compatibility]

["Christer Holmberg" <christer.holmberg at ericsson.com>]

Hi, 

>If we are going to change MSRP to enable SBCs or any other sort of 
>middlebox, I'd really like to see more documentation on how that 
>middlebox is expected to behave in context, and how the whole 
>architecture works when said middlebox is present. I'm not necessarily 
>talking about normative specification.This is the point I was trying 
>to get across in previous reviews when I suggested we needed some use 
>case analysis and possibly call flows to describe the requirements 
>that section 4.2 sets out to solve.
>
>We spun up a whole working group (BEHAVE) to do this for NATs, and 
>subsequently learned that many of or generally held assumptions were 
>wrong.
>
>I agree wholeheartedly with Ben's sentiment regarding the assumptions
we're making about SBC behavior, and I think the comparison to NATs is
quite appropriate. Saying that SBCs operate "by modifying the 
>SDP"[1] is as useful as saying that NATs operate "by changing IP
addresses." You can make certain assumptions about what these changes
look like, but they're just assumptions. And right now, they're not 
>even documented assumptions.

ACM is not standardized yet, so we don't need to make any assumptions
regarding how existing intermediates modify the path attribute etc. If
they DO modify the path attribute, legacy MSRP won't work, and it
doesn't matter what we do.

What we need to do is to describe how ACM routing etc work. People will
then have to make sure that intermediates who are supposed to support
ACM will act according to that - as for any other meida (we haven't
specified how intermediates shall modify the c-line for audio etc).

>We've been down this road before. For example, we spent a lot of work
to develop a protocol to characterize NATs based on untested assumptions
about NAT behavior.

Unlike NAT behavior, there is no existing ACM behavior, so we don't need
to make assumptions on how intermediates work regarding ACM.

Personally I also think that the NAT behavior issue is far more
complicated than intermediate behavior for MSRP ACM.

Having said that, I have no problem to document how an intermediate
which is to support ACM is expected to behave when it comes to modifying
the SDP etc, if we think that is useful. But, we don't need to make
assumptions about existing ACM support in intermediates.

Regards,

Christer


>It was only after we actually spun up BEHAVE and did the work
documented in draft-jennings-behave-test-results that we realized we had
wasted vast man-years of engineering resources for naught. RFC 3489 
>stands as a tombstone to our hubris and carelessness.
>
>I am certain that we have relevant lessons to learn from BEHAVE, and
that many of them fall in the category of "trying to engineer protocols
around an undefined entity is folly."