Re: [dispatch] Thoughts on draft-rosenbergjennings-dispatch-ripp-03

[Jonathan Rosenberg <[e-mail]>]

Thanks Roni for the comments!

Though quic overall is reliable, the way we’re using it achieves an
interesting effect - there is no hol blocking. This means an actual IP loss
would result in packet 1 showing up, then 3, then much later, 2. As a
result, with hitter buffer, 2 is effectively lost and thus fec would be
useful in recovering 2.

Thx,
Jonathan R.



On Mon, Jul 22, 2019 at 7:16 AM Roni Even (A) <[e-mail]> wrote:

> I agree with Eric’s comments.
>
> I was also wondering about the capabilities support. For example OPUS
> supports in band FEC which addresses packet loss but if you use a reliable
> transport it will lose the effectiveness of FEC.  This is why there is some
> discussion about unreliable streams.
>
> It look to me that replacing RTP is not as simple as you present in the
> document.
>
> Roni Even
>
>
>
> *From:* dispatch [mailto:[e-mail]] *On Behalf Of *Eric
> Burger
> *Sent:* Monday, July 22, 2019 12:18 AM
> *To:* [e-mail]
> *Subject:* [dispatch] Thoughts on draft-rosenbergjennings-dispatch-ripp-03
>
>
>
> General: For the most part, I like the idea of a draft that basically
> says, “we tried to be pure but failed. This proposal is not pure but it for
> the most part represents running code.” PHB will be happy (ref. the NAT
> discussion on the IETF list).
>
>
>
>
>
> Section 1.1: background
>
> Will much of it be meaningful to a protocol implementer in a year, no less
> five? I.e., referencing Kubernetes, Istio, CanaryDeploys, etc., more
> especially without going into detail as to what they are? Sure, if you are
> an AWS developer you know them like the back of your hand. However, not
> many folks in IETF-land are.
>
>
>
> 1.2:
>
> Why is it ‘unfortunate’ that people want to deploy cloud applications that
> interact with the PSTN? Is that not an opportunity? I would take out the
> initial “Unfortunately.” It’s just a statement of fact that applications
> like to call and be called to most any person on the planet on a fully
> interoperable basis.
>
>
>
> There needs to be more justification than “Web people don’t understand
> SIP.” You might want to explain how RIPP is different than ParlayX. I would
> offer that RIPP:ParlayX::LDAP:X.500, but you don’t say that anywhere. All
> the draft implies is Web people cannot grok SIP and SIP does not grok Web
> deployment, which does not reflect well on either community.
>
>
>
> The last paragraph of 1.2 implies that SIP is the source of robocalls and
> a mechanism that will be even easier to inject boatloads of calls will be
> better. Please explain how this will be so (or remove the assertion). As
> you know, I personally wish it would be so, so PLEASE give me ammunition!
>
>
>
> 1.4:
>
> Given the virtual mandate to use SIP over TCP, is saying “we can finally
> use HTTP over UDP” not kind of a retrograde assertion?
>
>
>
> REQ 12 (supporting only audio) is an odd requirement. Moreover, most
> applications in the U.S. would require at least RTT support if not video. I
> am not a lawyer, but since we are talking interoperability with the PSTN,
> one is likely to run into Section 255 and 706 issues if RTT (and video) is
> not there from day one.
>
>
>
> REQ 13 looks totally duplicative of REQ 10 (use secure caller ID
> technologies). Is there a distinction? If so, please make it clearer
>
>
>
> Section 3.6:
>
> This is a place where we need to distinguish between theory and reality.
> In theory, SIP could provide end-to-end media security. In practice, no one
> figured it out. The good news is RIPP is no worse than SIP as it is
> deployed today. Moreover, RIPP is no worse than HTTP. My concern is RIPP
> structurally will never have end-to-end media security. While that is no
> worse than today, will we be running into some privacy expectations of
> users and regulators? For example, a RIPP server can record everything.
> Problems here are (1) in the U.S. that is likely to be a violation of the
> Wiretap Act and (2) people can use those recordings for very nefarious
> purposes (see RealTalk, Lyrebird, etc.).
>
>
>
> Section 8.2:
>
> Just curious: why MUST NOT the identifier included the authority component
> for uniqueness? Is that a Web best practice? A reference or explanation
> would be helpful.
>
>
>
> Section 8.3:
>
> What are the capabilities *of*? Are they codec parameters? Are they
> decoded stream parameters? Are they codec dependent? Is there any value to
> these parameters, outside parameterized codec negotiation that I am missing?
>
>
>
> For example, is the max-bitrate the decoded maximum bitrate or the bitrate
> of the codec? What is the purpose?
>
> If I come up with a cool LPC that can do better than G.711 with 4000
> samples per section, why cannot I use it?
>
>
>
> BIG ONE: force-cbr
>
> Do we require a CBR codec or do we require uniform packet sizes (in
> bytes)? If the former, why not just ask for a CBR codec in the request. If
> the latter, change the parameter to something like “require privacy.” There
> are much better ways of achieving privacy than using a CBR codec; see e.g.,
> https://repository.library.georgetown.edu/handle/10822/1040699
>
>
>
> Section 8.4:
>
> I agree with Cullen. It goes against the design principle of using HTTP/3
> for transport and then start putting application semantics into the
> transport layer. Is there a reason to break layers, e.g., for load
> balancing or something else?
>
>
>
> Section 8.7
>
> Why 20 for forward and 10 for reverse? Are these rules of thumb,
> calculated optimal places to start, SWAGs, or irrelevant?
>
> Also (and in Section 8.8), what about the speed of light and the
> appearance of blocking?
>
>
>
> Section 8.8
>
> Perhaps I missed it, but what happens if a byway appears to be blocked for
> a ‘while’? Since this is voice and this is UDP and I am tolerant of packet
> loss, do I care a packet was lost? Also, I’m highly skeptical of 1:1
> packet:ack this protocol offers. That sounds like a bad thing for LANs and
> a terrible thing for WANs. Really?
>
>
>
> Section 8.10
>
> I kind of agree with Cullen’s point, but here is an opposite observation
> that I came up with before I saw Cullen’s point (that SIP result codes
> don’t cover ISDN). Why have a separate ‘rejected’ result in light of
> ‘failed.’ Unless rejected is referencing the SIP 607 result code, I would
> think all the call center cares about is whether the call completed and if
> it did not, will a retry be likely to succeed or fail.
>
>
>
>
>
> There are a ton of typos in the draft. I’d be happy to hand my mark-up to
> whomever wants it in DISPATCH.
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch
>
-- 
Jonathan Rosenberg, Ph.D.
[e-mail]
http://www.jdrosen.net