Subject: [Int-area] Wrapping up post IESG evaluation discussions on draft-ietf-intarea-frag-fragile

From: Suresh Krishnan <[email-masked]>
Date: Tue, 1 Oct 2019 20:57:45 +0000

Hi all,
  The text changes in version -16 of this draft for the resolution of Alissa Cooper’s DISCUSS position resulted in lively discussion on the mailing list. The authors have made another revision of the draft (version -17) to address the comments raised during this discussion. If you believe that any of your substantive points have not been addressed please respond to this mail stating what they are. As the responsible AD, I believe that the draft is ready to move forward and be approved, and I would like to do so by end of day on October 8th 2019 in the absence of any actionable objections. 

Thanks
Suresh

---

From: Fred Baker <[email-masked]>
Date: Wed, 2 Oct 2019 10:35:16 -0400

So I'm reading NANOG and finding a certain thread interesting in this context. Look in the archive (or if you follow it, just look at your archive) for the subject line "Spectrum (Charter) Fragmented UDP".

> On Oct 1, 2019, at 4:57 PM, Suresh Krishnan <[email-masked]> wrote:
> 
> Hi all,

The point made this morning is that telephones have horrible TCP implementations:

> From: Phil Lavin <[email-masked]>
> Subject: RE: Spectrum (Charter) Fragmented UDP
> Date: October 2, 2019 at 8:59:42 AM EDT
> To: Saku Ytti <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> 
>> While we can say this should just work, the reality is, it's not very reliably true and I would not build product or business on the assumption that it works well.
> 
> Yup. Understood. We can't get away from sending multi-packet messages. We try our best to keep SIP messages as small as possible though sometimes certain optional features required by customers push it beyond their MTU. We're also starting to see decreasing MTUs as customers deploy various SD-WAN solutions and it's tough to keep up with these when you're already teetering on the edge of what used to be considered a fairly common minimum MTU value.
> 
> We can, of course, get away from using UDP. We can and do run SIP over TCP and indeed over TLS on TCP though the stateful nature of TCP often makes this undesirable. We see a lot of SIP phone implementations that do not handle TCP connection failures very well and result in a loss of calls for a period of minutes if this happens, as they take a while to notice the connection has dropped and should be re-established. Pros and cons of each.
> 
> If anyone has any specific information about Spectrum CPE changes or indeed any contacts who may be able to interrogate this internally within Spectrum that would be appreciated.

What we are saying in this draft is that such things ought not to be. Do we have practical advice in context? "Fix your TCP and use it"?

---

From: Fred Baker <[email-masked]>
Date: Wed, 2 Oct 2019 10:40:21 -0400

A follow-up note in the thread pointed out that STIR/SHAKEN has large SIP messages. This particular issue may solve itself as companies deploy STIR/SHAKEN and talk with their vendors...

> On Oct 2, 2019, at 10:35 AM, Fred Baker <[email-masked]> wrote:
>