default ECN settings

[Midori Kato]

Hi Macy and Don,

I am Midori. Too late to catch up this topic but this topic is interesting
to me.
Linux separates inbound and outbound ecn operation while RFC 3168 says that
making hosts fail during the negotiation without ecn configuration.

I think FreeBSD is probably able to distinguish inbound and outbound with
cc_var flag as well.
I like to try to work this. If the sender like to use ECN, behaving as ECN
receiver is good for the TCP connection.

Regards,
-- Midori


2015-09-05 10:05 GMT+09:00 K. Macy <kmacy at freebsd.org>:

> On Fri, Sep 4, 2015 at 5:53 PM, Don Lewis <truckman at freebsd.org> wrote:
> > On  4 Sep, K. Macy wrote:
> >> By default ECN is completely disabled on FreeBSD. On Linux the default
> >> is to disable it outbound (not request it) but enable it inbound
> >> (accept new connections asking for it). Is there a good reason to only
> >> set ECN_PERMIT on inbound connections if the system is doing ECN on
> >> outbound connections?
> >
> > Not that I can think of.  The risk in enabling ECN for outbound
> > connections is that some connection attempts can fail, especially if you
> > are attempting to connect to some old and oddball device.  That should
> > not be a risk for inbound connections since those devices won't be
> > requesting ECN.
>
> Even with 'oddball' devices the stack is configured to retry ECN n
> times where n defaults to 1 and then revert to not requesting ECN
> support. Thus connections would take longer on 'oddball' devices. The
> solution that *I* would choose for that would be to track ECN support
> in the host cache. The first connection to a new host would always try
> ECN and in the event that that failed all subsequent connection
> attempts would not try ECN. To me this seems like the most robust
> compromise. However, I don't yet have enough information to say how
> much benefit this would confer.
>
> > Seems like we should be defaulting ECN on for inbound connections,
> > though we currently can't control the two directions separately.
>
> That is a straightforward change.
>
>
> Cheers.
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>