Re: [tram] STUNBIS: Retransmissions over TCP

["Gonzalo Salgueiro (gsalguei)" <[e-mail]>]

Hi Olle -

On Jul 27, 2016, at 12:23 AM, Olle E. Johansson <[e-mail]<mailto:[e-mail]>> wrote:


On 26 Jul 2016, at 14:50, Muthu Arul Mozhi Perumal <[e-mail]<mailto:[e-mail]>> wrote:

The use cases I've heard are:
1. A (broken) middle box doing TCP<->UDP inter-working: If the message get lost on the UDP side and the transmissions are handled by the TCP stack (in the kernel), the middle box may not retransmit the message over UDP causing problem for endpoints.
2. Mobility: If the IP address changes, TCP may not know whether the message was sent or not.

These are what I've overheard, though I haven't come across the problem myself..
THank you for your feedback!

I think there is something here to explore for STUN and the various usages, but we may not
be ready to open up StunBIS for it.

After some discussions we agree that there isn’t quite enough consensus to make such a profound change to the spec.  I think there is something interesting here to consider, but it feels premature for this version.

Cheers,

Gonzalo

It is a middlebox problem we need to handle, and I think
that STUN is a tool developed to discover middleboxes - NAT was the first one. The STUN RTT
measurement come in handy here, as the report I referred to clearly sees different latencies
depending on direction indicating that a TCP proxy was in the path. Maybe the RTT draft needs
to consider one-way too in order to assist detection?

/O

Muthu

On Tue, Jul 26, 2016 at 5:39 PM, Simon Perreault <[e-mail]<mailto:[e-mail]>> wrote:
Le 2016-07-26 à 05:23, Olle E. Johansson a écrit :
> Section 6.2.2:
>
> "Reliability of STUN over TCP and TLS-over-TCP is handled by TCP
>    itself, and there are no retransmissions at the STUN protocol level.”
>
> When using STUN over mobile networks, I think this is a bad assumption.
> We’ve seen many times that TCP proxys cause TCP to fail and they don’t follow
> the original intention of TCP. The SIP message fails, even though TCP confirmed
> delivery. I’ve got confirmation from a few developers that they started to send UDP-style
> retransmits over TCP to get around this.

I think this will be met with incredulity and responses along the lines
of "pcap or GTFO". :)

I admit I'd like to see a more detailed description of the problem
before we mandate such a profound change in the protocol. Would you be
able to get one of those developers to come talk to us?

> As a discovery protocol, I think we need STUN to discover situations like this.
> I know it’s not religiously correct, but retransmits over TCP unfortunately makes sense
> in today’s broken network, especially for a protocol designed to discover middle boxes.

To be clear: you actually mean sending a second Binding request on the
*same* TCP connection, right? Not opening a new one?

Simon

_______________________________________________
tram mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tram

_______________________________________________
tram mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/tram