[tcpm] 答复: New Version Notification for draft-you-tcpm-configuring-tcp-initial-window-00.txt

[Youjianjie <[e-mail]>]

Hi Michael, Joe,

Please see my comments inline...

BR,
Jianjie

> -----邮件原件-----
> 发件人: tcpm [mailto:[e-mail]] 代表 Michael Welzl
> 发送时间: 2014年10月24日 15:58
> 收件人: Joe Touch
> 抄送: [e-mail]
> 主题: Re: [tcpm] New Version Notification for
> draft-you-tcpm-configuring-tcp-initial-window-00.txt
> 
> Hi Joe,
> 
> In line:
> 
> 
> On 23. okt. 2014, at 16:38, Joe Touch wrote:
> 
> >
> >
> > On 10/22/2014 1:46 AM, runabk wrote:
> >> Hi all,
> >>
> >> On 2014-10-22 01:59, Joe Touch wrote:
> > ...
> >>> - IW cannot be determined at the time of the connection per se The
> >>> only way to do so would be to send IW segments into the net and see
> >>> if they get there, which isn't so much a probe as just using that
> >>> value as the initial window anyway.
> >>>
> >>> I continue to believe that IW can be adapted over loooong periods of
> >>> time using information on past connections as network behavior
> >>> evolves as per draft-touch-tcpm-automatic-iw-03.txt, but more
> >>> experience is definitely needed.
> >>>
> >>
> >> In the draft ``draft-touch-tcpm-automatic-iw-03.txt", All the
> >> connections at a particular instance start with nearly same IW value
> >> --- a single constant window for all flows.
> >
> > I had been assuming 2140-style grouping of information based on
> > network interface, destination IP address, destination subnet, etc.
> 
> ...which I'm not sure would be a good idea here, see my previous response to
> Hagen and also further below.
> 
> 
> >> My point is, why not to take a look on flow characteristics. I played
> >> with a lot of simulations and experiments.
> >> In my simulations in ns2, I considered a combination of flow types
> >> based on sizes --- large flows from Pareto Distribution, and small
> >> flows from Exponential Distribution. And we observed, large flows
> >> having a small IW, and even randomly choosing a large IW for small
> >> flows gives better performance than all the flows with IW10;
> >
> > Large flows are not as affected by IW effects because IW applies only
> > during transients that are presumably rare (startup, restart after
> > idle,
> > etc.)
> >
> > The problem with your observation is that it fails to consider the
> > "tragedy of the commons". Capacity is a common network resource, and
> > your increase of IW for short flows causes them to consume that
> > resource before feedback corrects it in ways that are not generally
> > considered "fair".
> 
> So you're arguing that this work creates an incentive for applications to make
> their flows shorter? Interesting. An application cheating the system by splitting
> a large flow into small ones would have to weigh the benefits of being able to
> use a larger IW against the cost of the handshakes for closing and re-opening a
> connection, at least. Depending on the IW calculation function in use, there can
> be corner cases where such cheating might work, I think this should be
> addressed in the draft.
> 


If the applications are not trusted, then the system could add some constraints, such as maximum IW. This value could be configured by the system. Meanwhile, the IW of the receiver should also be considered. If the application are trusted, then this is not an issue. Shall we add such descriptions in the draft?


> > I.e., it's been known for a long time that making IW large helps short
> > flows and has no real impact on long flows. It's also been known that
> > this is not necessarily how we want the network to behave.
> >
> > There's a balance between trying to complete a short flow quickly and
> > having flows that are basically non-responsive to network congestion.
> > We only recently increased IW to 10 based on the assumption that "a
> > problem we haven't seen doesn't exist".
> >
> > ...
> >> A constant IW may not be suitable.
> >
> > If you have 2140 in place, you might have the information useful to
> > set an appropriate IW on a per-connection basis. However, setting that
> > value solely based on the length of the connection is (IMO) inappropriate.
> 
> So, I think it's the most appropriate thing that can be done, and RFC 2140 can
> end up being less appropriate:
> 1) if you reduce IW on later connections to a host you're already talking to
> (ensemble sharing) or have talked to before (temporal sharing), ECMP may put
> you on a different path and you may end up being too conservative.
> 2) if you ONLY apply 2140-style IW reduction, you may not be conservative
> enough because all these first connections to various IP addresses start with
> IW10  (which may not seem to matter if we think about it from the
> perspective of a single web server, but certain web pages open many *first*
> connections from many different IP addresses to my browser, so then it's my
> access link that suffers).
> 
> At the same time, using IW10 on large transfers is just useless. So I think
> incorporating the flow length in the decision to only use a large window when it
> can make sense is the best we can currently do.
> 
> Cheers,
> Michael
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm