Subject: RE: [Tsvwg] Re: HighSpeed TCP for Large Congestion Windows

From: [email-masked]
Date: Mon, 26 Aug 2002 09:44:11 -0400

Joe,

Thanks for your comments.

> The other issue is whether such traffic needs
> to be done in a protocol modified in a public forum.

IP-based protocols developed in private have this unfortunate
habit of emerging in public.  One advantage of doing work in
public is that the wisdom of this community can be taken
advantage of in areas like congestion control.  As Sally
has explained, the desire to run at these kinds of rates
and evidence that TCP has issues in this area are
emerging.  One way to view her draft is an attempt to
find/apply the proverbial "stitch in time" - an example in
a related space of what can happen when this isn't done is
that in 20/20 hindsight, running NFS only over TCP (as is
done in most cases today) would have saved a lot of grief
caused by unwarranted assumptions about UDP's level of
reliability and resilience to "stupid network tricks".

> In both of these cases, much of the traffic is across dedicated
> links.  In those cases, TCP can be modified and used over those
> links without affecting the rest of the Internet.

Yes, but it'd be nice to do those experiments in a fashion that
could be useful over the Internet in the event that they're
successful.  That's an important rationale for working on the
draft in this community.  There's no lack of folks who have been
and are happy to design their own transport protocols that won't
behave well in the Internet.  While I can't speak for Sally, I
have no problem with "experimental" status for her draft - at
this stage, I'm much more interested in understanding what the
proverbial "right thing" to do is than making it a standard.

> > At the moment, all of the IP Storage protocols can spread their traffic
> > across multiple TCP connections, and hence can keep congestion windows
> > down in that fashion, but we'd like to have the opportunity to use fewer
> > TCP connections to get the job done in a simpler fashion.
> 
> Using multiple connections is just cheating, congestion-wise. 
> See RFC-2140.

No argument here - as I described earlier, that was not the major
reason for putting multiple TCP connection support into the IP Storage
protocols.  Using it adds complexity, but it's a tool that's available
if necessary ... and calling it "cheating" hasn't deterred the grid FTP
folks either.  If there's no other way to solve the problem, multiple
connections will be used.  I would hope that people would take some
interest in providing a better solution (something approximating the
proverbial "right thing to do") as opposed to just labeling the
obvious work-around as "cheating".  In this regard, I greatly
appreciate Sally's efforts and willingness to take the "pioneer"
arrows in her back ...

Thanks,
--David
---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 249-6449            FAX: +1 (508) 497-8018
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------
_______________________________________________
tsvwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Joe Touch <[email-masked]>
Date: Mon, 26 Aug 2002 09:11:29 -0700

[email-masked] wrote:
> advantage of in areas like congestion control.

David (et al.),

This forum is not the only place where good protocol design is applied 
or considered. The question is whether it is relevant - at this point - 
to consider preliminary work.

While Sally certainly made the point that there is a problem, the number 
of components in the related solution alone suggests that there is a 
more fundamental issue here. It would be useful to consider this 
"research in progress", rather than "standards in progress". It's not 
clear that this WG is the best place for the former (though it's clearly 
useful to keep the WG members informed via the mailing list).

> draft in this community.

Keeping the WG informed isn't the same as making this a WG agenda item.

This WG has in the past been fairly conservative about taking on agenda 
items, notably experimental ones, considering the conservative approach 
about modifying TCP.

> protocols.  ...   I would hope that people would take some
> obvious work-around as "cheating".

The best way to cheat is to cheat. It's unlikely that multiple TCP 
connections would be used if they just "did the right thing" - they do 
it more aggressively. Any alternative that isn't as aggressive isn't 
likely to be considered a viable alternative.

> In this regard, I greatly

This WG has plenty of "pioneers" who have taken arrows (all of whom are 
appreciated); the group typically shoots this sort of thing down as  a 
WG item as premature (i.e., appreciated != WG item). There is 
insufficient motivation in this case to warrant an exception.

Joe