Re: [tcpm] no meeting at Maastricht?

[Jerry Chu <[e-mail]>]

Hi Wes,

On Fri, Jun 25, 2010 at 1:11 PM, Eddy, Wesley M. (GRC-MS00)[ASRC
AEROSPACE CORP] <[e-mail]> wrote:
>>-----Original Message-----
>>From: Jerry Chu [mailto:[e-mail]]
>>Sent: Friday, June 25, 2010 3:45 PM
>>To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
>>Cc: [e-mail]
>>Subject: Re: [tcpm] no meeting at Maastricht?
>>
>>Hi Wes,
>>
>>How about other proposals that are still waiting to get on the WG
>>agenda?
>>(http://www.ietf.org/id/draft-hkchu-tcpm-initcwnd-00.txt
>>http://www.ietf.org/id/draft-paxson-tcpm-rfc2988bis-00.txt)
>>
>>Since our "Increasing TCP's Initial Window" proposal in Anaheim, we've
>>done
>>more experiments and have a lot more data to present. We've also been
>>hard
>>pressed to make forward progress. I was hoping to meet you and many
>>others
>>f2f in Maastricht to discuss our data. It looks like the alternative
>>is ICCRG. (A request for presentation slots has been sent to ICCRG.)
>>
>
>
> Hi Jerry, thanks for the update.  In both cases, would it be possible
> to get some of that new data out to the list?  I think people would
> appreciate having time to look at it rather than seeing it for the
> first time in the meeting.  As we found in Anaheim, there's more
> data then there is ample time to set the context, present it all, and
> answer questions about it, plus have the discussion about next steps.

Understood. Note that for Anaheim we published our data (in a paper)
weeks before the meeting so it wasn't like people saw the data for the
first time in the meeting. We hope to do the same this time. It's just that
there has been a lot of work and we don't know how soon it can be
completed... But will certainly try to publish the data as soon as we finish
the analysis.

>
> On the 2988bis document, since it's been discussed on the list and
> in person for a while, and evolved based on feedback, I'd guess it's
> time that we poll the list for adoption as a WG item; if you agree,
> we can kick that off.

Yes, there have been some good questions and discussions, both at
Anaheim's meeting and from the list. Although not all questions have been
adequately answered, none of them seem to be directed to the overall
feasiblity or usefulness of the draft. Therefore they should not be a gating
factor toward WG adoption. (Right?)

>
> The way we left Anaheim's meeting was, I think, that you were going
> to update the draft to talk about why the minimum RTO isn't proposed
> for reduction as well,

Well, it was more like someone asked why reducing minRTO wasn't
included and I asked why should it be included? (I.e., why must the two
be bundled together?)

Mark Allman also provided some explanation to the list.

Frankly I'm not objecting to the idea of reducing minRTO at all - Linux and
some other OSes have done that for years. But in-between other work we've
taken on (e.g., the raising IW proposal) and our day jobs we're stretched
very thin now. I think it's only fair for those who have asked about it to pick
up the work themselves, isn't it?

>think about the effect on slow links with a
> long RTT, and potential effects of the lower RTO on other (non-HTTP)

The draft has been designed specifically to minimize the impact of sprurious
RTO. There was also a question at Anaheim meeting regarding the possible
interaction between the IW=10 and the initRTO=1sec proposals. Specifically
if IW has been changed to ten and 10 pkts were sent through a slow link of,
e.g., 128Kbps, it will take more than 1sec to get all 10 pkts through (assuming
Ethernet MTU), hence incurring a spurious RTO.

My answer was that was not how the RTO timer works. (According to section
5.3 of RFC2988, the RTO timer will be restarted after each ACK that acks new
data. So the above spurious RTO won't happen.)

> applications.  If you want to add those prior to polling the WG for
> adoption of the document, it might help.
>
> Increasing the initial window was more hotly discussed both in TCPM
> and in ICCRG, but there doesn't seem to have been much follow-up
> discussion on the lists in the mean time.  There was clear interest
> in continuing to talk about this in TCPM, though I didn't get the
> impression that we were ready to ask TCPM to make it a work item
> yet.  I may be wrong.

What will be the criteria for a proposal to accepted as WG work item?
Isn't the interest level the primary one (besides the benefit vs cost and
feasibility equation. But one can argue the interest level should already
reflect that)?

I was a little confused by Lars' comment at Anaheim's meeting about
the actual work for the WG being small, implying perhaps a working group
only oversees the final "paper work". Yes the actual "paper work" as far
as amending RFC3390 to raise IW may be small. But the amount of
nvestigation work and large scale experiments and data analysis effort to
justify/validate (or even disapprove) the proposal are huge. It just sounds
very odd the latter are not conducted under the WG's guidance and
auspices.

Best,

Jerry

>
> I think this is the first agenda request for ICCRG in Maastricht, and
> people were really interested in it at the Anaheim meeting, so it
> should get ICCRG time in Maastricht.  We had decided in Anaheim that
> we wanted to avoid giving the same presentation to both groups again,
> so if TCPM doesn't meet, that makes it easy (half-kidding).  One
> suggestion was to have a joint meeting; this may be a good idea for
> Maastricht if the ICCRG chairs agree ;).
>
> --
> Wes Eddy
> MTI Systems
>
>