Re: [tcpm] [Tmrg] Increasing the Initial Window - Notes

[Aki Nyrhinen <[e-mail]>]

All of this makes me wonder.

If we are going to set one initial window for all, we make the
assumption that it works reasonably well for ALL. If we make it dynamic,
why does it suddenly have to be per destination?

Why can't it be just a single variable (or per actual routing table
entry, just to ignore connections to localhost, distinguish local lan
etc) that starts at some value, is incremented once a month and is
decremented if more than whatever number of clients the server owner is
happy to induce IW losses for, experiences them.

The state required to track this is simple enough that it can be
saved/restored at shutdown/boot. Tracking i imagine takes two integers
per possible IW: the number of connection attempts with that particular
IW and another for the experienced losses with that IW. i'm sure clever
people can come up with more compact representations.

I like Joe's proposal and while I agree we don't have any evidence on
how well such a thing would work in practice, I definitely don't think
it is automatically worse than just saying "IW is 10 until the next time
we start fighting over it".

	Aki

On Fri, 2010-11-19 at 10:48 -0800, Joe Touch wrote:
> Hi, Jerry,
> 
> The reasons you give for this all being too complex to deploy are great 
> reasons we cannot afford to take a risk on IW=10.
> 
> If you can't monitor it and tell us whether it works, you're seriously 
> asking us to just do it anyway, blindly?
> 
> Joe
> 
> On 11/19/2010 10:45 AM, Jerry Chu wrote:
> > On Fri, Nov 19, 2010 at 10:21 AM, Joe Touch<[e-mail]>  wrote:
> >>
> >>
> >> On 11/19/2010 9:58 AM, Jerry Chu wrote:
> >>>
> >>> Hi Joe,
> >>>
> >>> On Fri, Nov 19, 2010 at 9:23 AM, Joe Touch<[e-mail]>    wrote:
> >>>>
> >>>> Hi, Jerry (et al.),
> >>>>
> >>>> The logic here is astounding.
> >>>>
> >>>> We can't use a reactive system because it would make the wrong decision,
> >>>> and
> >>>> potentially treat all endpoints the wrong way.
> >>>
> >>> We can't use a reactive system like the one you suggested because it just
> >>> doesn't work (except in a few limited cases). We are debating on an
> >>> engineering
> >>> issue here and this is IETF so we'll need running code and real deployment
> >>> experience. If you can demonstrate your idea in a large server farm
> >>> environment
> >>> without requiring a large amount memory and complexity and actually
> >>> showing
> >>> reasonable performance latency I'll jump on it tomorrow!
> >>
> >> It's simpler than you're thinking, and doesn't require code in the data
> >> path:
> >
> > Well, it's not as simple as you think because the devil is in the details,
> > and we had to deal with all the details in order to perform real experiments
> > before giving up. (See my slides mentioned in previous email.)
> >
> >>
> >> 1) pick an IW s
> >>
> >> 2) keep stats on whether the IW works
> >>         this can be within every single connection, or done out of
> >>         band using tracers as separate machines
> >>
> >> 3) lower the IW if it tends to result in retransmits
> >> (possibly even increase it over longer timescales if it doesn't result in
> >> retransmits)
> >>
> >> This can happen on the timescale of days. Weeks even. I'm not talking about
> >> something that needs to happen in realtime.
> >
> > We've tried both the realtime and the offline schemes (again see my slides).
> > I've mentioned the problem with the realtime one in my previous email. For
> > the offline scheme, do you realize how many subnets are their even in just a
> > region, how much memory it requires, and how much work it takes to try to
> > import the data into the kernel and make it work efficiently?
> >
> > Again please show me your "simple" implementation and success experience.
> >
> > Jerry
> >
> >>
> >> The point is to automate the feedback mechanism that Mark and I discussed as
> >> necessary.
> >>
> >> Joe
> >>
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm