Re: [Perc] Minutes from Design Team call #3

[Lorenzo Miniero <[e-mail]>]

On Fri, 13 May 2016 12:05:18 -0500
Emil Ivov <[e-mail]> wrote:

> Hey Paul,
> 
> On 12.05.16 г. 21:27, Paul E. Jones wrote:
> > Emil,
> >  
> >> Hey Paul
> >>
> >> On Wed, May 11, 2016 at 6:12 PM, Paul E. Jones
> >> <[e-mail]> wrote:  
> >>>  Emil,
> >>>  
> >>>>  A) Because otherwise that scr*ws up authentication because we
> >>>> cannot keep track of the overwrites across RTP and RTCP:
> >>>> obviously this is not true as we could simply not use SSRCs for
> >>>> PERC-specific purposes and define PERC specific IDs  
> >>>
> >>>  I'm not following that one.  RTCP is HBH, so not an issue.  Why
> >>> would we
> >>>  need a PERC-specific ID?  
> >>
> >> My point is that if you need an immutable ID then you can define
> >> your own. As I already stated in this thread: that new ID can be a
> >> copy of the original SSRC or something new: whatever works.  
> >
> > We do not really need an identifier, except to address the one
> > security issue raised here:
> > https://tools.ietf.org/html/draft-mattsson-perc-srtp-cloud-01#section-7.2.4
> >
> > With the agreement reached (after a lot of discussion) back in
> > December not to change the SSRC, this issue no longer exists.  
> 
> Let's please get that reversed. We need SSRC and seq num rewriting to
> be possible so let's find a different solution to that *one* security
> issue that wouldn't make a bunch of implementers whine on this list
> every few months.
> 
> It is not a big deal for this WG's work. It has a huge impact on the 
> adoption of that work though.
> 
> >>>  I assume this is as an alternative to the SSRC in
> >>>  the cryptographic context?  We would not need that given "double"
> >>> defined a
> >>>  field that could record the original E2E SSRC value.  (Yes that
> >>> is now removed, but see below.)
> >>>  
> >>>>  B) You are not correct and I, who have never implemented an SFU
> >>>> in my life, am telling you that you can reimplement your SFU to
> >>>> not rely on SSRC rewriting and it will be a piece of cake. I
> >>>> hope I don't have to comment on B.  
> >>>
> >>>  It is indeed a fact that you can write a switching function that
> >>> does not
> >>>  require changing SSRCs.  
> >>
> >> Yes you can do that. You can also travel from Paris to London via
> >> Sydney: few people are making that choice though. All SFUs I am
> >> aware of overwrite SSRCs even if the one that you wrote might have
> >> taken a different path.  
> >
> > I'm scratching my head on this. ISTM that remapping SSRC is the
> > longer path from Paris to London.  
> 
> You will understand as soon as you try to implement an SFU that works 
> well with WebRTC today.
> 
> > I appreciate that you might not have seen all
> > of the products on the market;  
> 
> I am pretty sure I know about most of the WebRTC compatible ones.
> 
> > there certainly are some that do not
> > rewrite SSRCs.  
> 
> And they, whoever they are, would be just fine if we relaxed the 
> requirements on immutable seq nums and SSRCs.
> 
> > So, I am curious why you cannot build a system that just
> > leaves the SSRCs alone.  
> 
> I have already built my system. So have Google and Vidyo and Janus
> and Microsoft and Kurento. We are *all* rewriting sequence numbers
> and SSRCs.
> 
> >>>>  As an IETF WG, PERC's behaviour on this topic has been very
> >>>> confusing to me and I am almost at the point where willful
> >>>> disruption is the only possible explanation that I can find. If
> >>>> we do proceed to ignore implementers the same way we are going
> >>>> to find ourselves debating the same concerns in IETF last call
> >>>> where reason would have a better chance of prevailing.  
> >>>
> >>>  I think the issue is this: you've not attended the meetings.  We
> >>> had accommodated the option to change nearly everything in the RTP
> >>> header via
> >>>  the OHB in "double".  During a recent meeting, it was decided to
> >>> limit the
> >>>  scope of what can be changed.  We made the original "double"
> >>> proposal to
> >>>  allow for anything to be changed
> >>>  (https://tools.ietf.org/html/draft-jennings-perc-double-00) and
> >>> participants
> >>>  in the meeting said to reduce the possible set down to PT and
> >>> sequence number, so we produced
> >>>  https://tools.ietf.org/html/draft-jennings-perc-double-01
> >>> accordingly.  This
> >>>  change was proposed in a conference call, if I recall, and then
> >>> discussed
> >>>  face-to-face before the document moved forward to WG adoption.
> >>>
> >>>  I do not recall any person on a phone call or in the meeting
> >>> room who opposed the changes.  It came as a pleasant surprise to
> >>> the authors that
> >>>  everyone was agreeable to such a narrow set of fields that could
> >>> be changed.  
> >>
> >> I am stunned!
> >>
> >> Paul, we first had this very conversation five months ago:
> >>
> >> https://www.ietf.org/mail-archive/web/perc/current/msg00136.html  
> >
> > Yes, I recall the older conversation and, in fact, we had it in our
> > draft to allow the SSRC to change.  However, the decision to not
> > modify the SSRC followed email exchange and the decision has been
> > in place since at least early December.
> >  
> >> Numerous implementors commented here. This should have been the
> >> end of it.
> >>
> >> then a bit later I raised it again here:
> >>
> >> https://www.ietf.org/mail-archive/web/perc/current/msg00222.html
> >>
> >> Now this.  
> >
> > Yes, at the time it was an active topic of discussion.  The
> > decision was made, minutes reported, documents updated, etc.  I
> > think it is the rest of us who were participating in the meetings
> > who should be stunned at this issue being raised again.  
> 
> I cannot believe you are making that point. Did you at any point see
> any of the concerned implementers come back and say: "Oh right! That
> totally makes sense now! Forget about immutable seq nums and SSRCs,
> we can do with out them. Roll on!"
> 
> As a responsible document editor, *that* is what you should be
> looking for. Same for all actively participating WG members.
> 
> You know me, you know Lorenzo, you know Bernard I assume you also
> know people from the other companies/orgs implementing simulcast
> through SSRC and seq num rewrites.
> 
> Did you see them take part of the discussion? Did you take any steps
> to go and check with them?
> 
> "You weren't there to complain then, so get lost now" is a pretty bad 
> argument and I certainly didn't expect it from someone with your 
> experience.
> 


That's probably needless to say, but I obviously support Emil, Luis and
other implementors on this. Emil has already voiced my concerns much
better than I would have been able to do, so I won't add to that.

What I'd like to highlight, though, is that I certainly don't recall
such a decision being echoed on the ML, as I would expect in the IETF
typically, especially on an aspect that had seen such controversy. Had
this happened, we definitely would have made our point timely again,
and not 5 months later.

Lorenzo


> >> So are you now saying: "well Emil the issue is that you are not
> >> present on all meetings so every time we try to sneak this back in,
> >> you are not there to stop us and that's your problem!"  
> >
> > No, I don't expect anyone to be at every meeting.  However, you do
> > need to appreciate that the decision is now 5 months old the group
> > has long-since considered this issue closed.  
> 
> I fail to see how that is in any way relevant. The concerns were
> stated before the decision was made. The people having made the
> concerns were absent when it was decided to not address them.
> 
> This doesn't mean they didn't care. If they didn't they wouldn't have 
> stated them. This simply means that they trusted the WG to do the
> right thing.
> 
> It did not!
> 
> >>>  Can we support changing SSRCs?  Yes, we can put it back in.  We
> >>> will need to
> >>>  change the way we have the OHB encoded, but it's certainly
> >>> possible. 
> >>>>  E2E encryption is too important of a subject for us to botch
> >>>> this work.  
> >>>
> >>>  I can only encourage you to participate in meetings when they're
> >>> called and
> >>>  to comment on drafts as they're published.  Heck, even if you
> >>> cannot make a
> >>>  face-to-face meeting, the -01 draft has been out there since
> >>> March 21 and
> >>>  nobody commented on that change until this week.  
> >>
> >> It is one thing to encourage involvement when new decisions are
> >> being made. I support this and we are all doing our best.
> >>
> >> It is a completely different thing to require participation so that
> >> the same points can be made over and over and over again.  
> >
> > I think you're mis-characterizing the events.  The SSRC issue was an
> > active topic of discussion back in November / December.  We had to
> > settle how we were going to deal with every header field and Magnus
> > led that dialog taking us through a couple of hours of discussion
> > as we went through each and every header value.  That meeting was
> > held on November 30 and a recording for that meeting posted to the
> > list:
> > https://cisco.webex.com/ciscosales/lsr.php?RCID=2684921e717d4b45aadb88d9a8774ce5
> >
> >
> > The SSRC dialog was at 1:01:43 and we talked about it for about 20
> > minutes.  I think it might be worth your time to review that.
> > Maybe you have a valid point not raised by others in the meeting,
> > but I really think it's unfortunate that you re-raise this issue
> > after we revised the drafts and went through another IETF meeting
> > where the group adopted text based on this decision.  
> 
> I couldn't agree more. It is very unfortunate and so easily avoidable
> if only steps had been taken to ping the concerned parties.
> 
> Now ... can we please stop this arguing and just work around the
> issue with s.num/ssrc rewriting?
> 
> Please!
> 
> Emil
> 
>