Re: [tcpinc] Review of draft-bittau-tcpinc-tcpeno-01

[Eric Rescorla <[e-mail]>]

I should also mention several other points about this:

1. Chrome doesn't do SO candidates even though it has ICE-TCP.
TCP NAT traversal works so badly that the major argument for ICE-TCP
is to allow for clients to talk to public servers even if they are behind
TCP-only firewalls, and that doesn't require SO.

2. We just added ICE-TCP and we may also remove SO if experience
shows it doesn't help.

3. WebRTC has its own COMSEC so we would want to disable TCPCINC
for these settings in any case.

So I think this is really an argument in favor of "don't worry too much
about SO"

-Ekr


On Fri, Aug 28, 2015 at 10:18 AM, Eric Rescorla <[e-mail]> wrote:

> On Thu, Aug 27, 2015 at 11:56 PM, David Mazieres <
> [e-mail]> wrote:
>
>> Eric Rescorla <[e-mail]> writes:
>>
>> >>  1. Does TCP-SO really exist in the wild, and if so under what
>> >>     circumstances (NAT, no NAT, etc.)?
>> >
>> > TCP-SO definitely exists in the wild. We do it in Firefox's ICE stack.
>>
>> So I'm not familiar with ICE over TCP, though I see there's now an
>> RFC6544 on this.  Is that what firefox does?  That's great information.
>>
>> With RFC6544, could the controlling/controlled roles be used to break
>> ties?  E.g., with TCP-ENO, could the controlling peer just always set
>> b=1?
>
>
> The problem is that there are situations where each side thinks it is
> controlling
> ("role conflicts"). RFC 5245 has the tiebreaker field to resolve this.
>
> -Ekr
>
>
>