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

[Eric Burger <[e-mail]>]

Ah - after seeing this and Cullen's presentation I just figured out there is no ask of the IETF other than to please contribute to the research to solve the problem such that someday we WILL have a replacement for that 20-year-old legacy protocol and in a few cycles have a concrete proposal that we could form a Dispatch or work group. I'm all for that!
-------- Original message --------From: Jonathan Rosenberg <[e-mail]> Date: 7/22/19  12:51 PM  (GMT-05:00) To: Eric Burger <[e-mail]> Cc: [e-mail] Subject: Re: [dispatch] Thoughts on draft-rosenbergjennings-dispatch-ripp-03 Hi Eric - thanks for taking the time to read and for the thoughtful comments.Responses inline below - but as a high level response - right now we're less interested in the details of the spec (for which the authors themselves dont all agree...), but rather to see if there is interest in solving this problem. The co-authors will be working on prototyping from here, so if anyone is interested, let us know... goal is working code before next ietf.On Sun, Jul 21, 2019 at 6:24 PM Eric Burger <[e-mail]> wrote: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). Yes, this is very much a pragmatic spec, aimed at solving some very real-world problems (ie., i've personally been beating my head against the wall trying to usefully deploy freeswitch within Istio on GKE. Let me know if you figured it out - its all hard due to how different http is from sip.) Section 1.1: backgroundWill 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.Happy to remove later on. Right now its just looknig to motivate the problem.  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.Stray word from a few rounds of edits, will remove thx. 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.No - its not about how well people understand anything. Its about how applicable modern cloud paas is to SIP and real-time services (which it really isnt), and how easy it is to build real-time apps which follow established design patterns for scalable and reliable systems (its super hard if not impossible).  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!It mandates passport as the one and only way to even know the caller ID. COnsequently, the protocol drags stir along for the ride. There is no other special magic or anything.  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?I wasn't being specific enough here. "SIP" refers to the whole community of specs needed for it, and this specific sentence is referring to RTP. I'll change to RTP. 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.I dont object - was just trying to start simple and solve one specific problem well. Do current SIP trunking providers support RTT and video?  REQ 13 looks totally duplicative of REQ 10 (use secure caller ID technologies). Is there a distinction? If so, please make it clearerBug - thx. 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.).I would assert that RIPP would be better than SIP today. There is a lot of SIP trunking out there (note RIPP *only* addresses inter-domain trunking cases, so thats the point of comparison). Most SIP trunking interconnection is over private IP with no TLS or SRTP. There is also some over public Internet, I suspect much of it is without SRTP and probably runs over VPN often. So, a peering protocol which requires hop encryption of signaling and media, and actually authenticates both sides, is a big improvement over the current situation.E2E encryption isnt really relevant for the applicability of RIPP, since it is targeted at inter-domain connectivity towards PSTN. PSTN as you well know has no e2e encryption, and there must be decryption at the pstn gateway. I dont follow how having a server at the edge of a provider network might be in violation of the wiretap act, or somehow make recordings worse. THis is no different than the situation today with SBCs, where the vast majority have no SRTP at all, and even those that do, are decrypting so they have access to the media.  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.THis is the text:"The path component MUST   be a globally unique identifier for this trunk, and not depend on the
   authority component as part of the namespace for purposes of
   uniqueness."The main motivation is to eliminate the need for wildcard certs to authorize:https://12345abcdef.ripp-provider.com requires one, whereas:https://ripp-provider.com/12345abcdef does notI'll include a mention on that, thanks. 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?THese are the capabilities of the ripp trunk. These are things normally configured as capabilities/configuration of sip trunks today. Codecs, bitrates, etc. They avoid the need for per-call capabilities exchange. Practically speaking, such exchanges are un-needed since the capabilities are static properties of the configured sip trunks. Again, we're not replacing sip overall - just providing a solution for inter-domain peering for voip to the pstn. 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?No this is the max codec bitrate, same as current RTP definition. Meant more for like opus.The protocol of course is extensible to new codecs - each side advertises the codecs they support and their associated max rates. If someone however says they dont want to receive 4000 samples per second, they'd advertise a lower upper bound. This part is really no different than offer/answer. BIG ONE: force-cbrDo 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/1040699Cullen was the one who wanted this one - so he's better positioned to speak to it. There was a study that found you could actually figure out what was being said just by looking at patterns of lengths of variable bitrate audio codecs. 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?Adding http headers is very common for web apps, so this isnt really different from normal web practice. That said, i dont feel that strongly on this one. Per above, right now its not so much about the specicic details of this proposal, as it is a starting point strawman for working on the problem. Section 8.7Why 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?TOtal SWAGs right now - we need some implementation experience to make this a more usable spec.Not sure I follow what you mean by speed of light? Section 8.8Perhaps 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?We didnt spec out yet what happens if its blocked for a while. This would happen under significant packet loss, so things are really bad. Probably drop the call.Do you care if a packet is lost? in normal voip cases, no. There are some use cases where the retransmission would be handy (same reason we have an RTP extension for it..)On the 1-1 packet:ack - thats a good comment. Definitely a drawback. Would be better if its piggybacked on reverse media, but we also currently have reverse media in separate byways. SO thats a tradeoff to be explored. Section 8.10I 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.Rejected is meant to handle the case, like mobile, where the end user actually hits the decline button. There are a ton of typos in the draft. I’d be happy to hand my mark-up to whomever wants it in DISPATCH.Thanks! Probably not worth fixing till we've gotten more experience under our belt and revised it to reflect that. _______________________________________________
dispatch mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dispatch
-- Jonathan Rosenberg, [e-mail]://www.jdrosen.net