Re: [tcpm] no meeting at Maastricht?

["Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]" <[e-mail]>]

>-----Original Message-----
>From: Jerry Chu [mailto:[e-mail]]
>Sent: Monday, June 28, 2010 4:50 AM
>To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
>Cc: [e-mail]
>Subject: Re: [tcpm] no meeting at Maastricht?
>
>>
>> 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?)



I agree; at least that was my impression of the feedback so far.




>>
>> 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?



I was only asking if the discussion on this would be captured in
the document, not suggesting that the work should be done to
consider minRTO reduction.  This would help it to be picked up
and worked on later, for instance.



>>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.)



Right; it seems like the document should mention that since it would
possibly be a common question.



>> 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.



To hopefully clarify a little: A WG item will have a milestone on the
charter page that says what type of document we're going to publish
and when we think it will be ready for submission to the IESG.  Since
the verification of whether or not the change has significant
negative impact isn't done and we don't know how long it will take,
but all agree that it's hard work, it's odd to put a milestone on that
says we'll produce a document making the change effective by some
date ... since we don't even seem to have consensus that the change is
good.

What we do seem to have consensus on, is that the proposed change
should be studied more deeply in the working group.  I would imagine
that at some point when you feel there's a critical mass of analysis
available that we would poll to adopt the document for publication
with a short turn-around time between adoption and sending to the
IESG.

Hopefully that makes sense; maybe someone will have a better idea for
how to process it.

--
Wes Eddy
MTI Systems