Re: [tram] STUNBIS: Retransmissions over TCP

Dear All,

This conversation is starting out in the right place (thank you, Olle), and
what TRAM needs to do with STUNbis NOW should stay in TRAM, but I would
appreciate someone summarizing what folks are seeing, with appropriate
references, to TSVAREA.

The larger conversation is something TSV needs to know about.

Thank you all.

Spencer, as TRAM AD

On Jul 27, 2016 02:23, "Olle E. Johansson" <oej@edvina.net> wrote:
>
>
>> On 26 Jul 2016, at 14:50, Muthu Arul Mozhi Perumal <muthu.arul@gmail.com>
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. 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 <sperreault@jive.com>
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
>>> tram@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tram
>>
>>
>> _______________________________________________
>> tram mailing list
>> tram@ietf.org
>> https://www.ietf.org/mailman/listinfo/tram
>
>
>
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram
>