Mark,
It seems good to encourage more discussions, even thesis projects, on what
sort of transport could be designed that would make better use of the varios
physical-layer links under consideration here. For example, the original
Internet transport was designed to run over virtual-circuit links with certain
characteristics, using intentionally simple flow and loss-control algorithms
(I had the fortune to discuss a few things today with George Conant, who wrote
the first finite-state-machine-plus-Algol representation of TCP, from the
Engish spec Cerf sent him in '78).
If, say, a high-delay physical layer were capable of high reliability, due to
error correction, as well as savvy retransmission, as others have mentioned,
the use of standard (if there is one) TCP on top would not be an optimal
choice. It would be more useful to consider the lower-layer's reliability and
make use of less complex, but perhaps more astute sequencing and flow-control
behavior at the transport. There is, for instance, even with TCP SACK, not a
good way to distinguish router loss from line loss -- a key distinction that,
when missed, hurts performance greatly when using TCP. TCP/IP, taken as a
whole, has potential for making some distinctions here, but hasn't been so
designed. Therefore, it seems that when we're dealing with data paths for
which our old transports have not been designed, even with extremem parameter
adjustments, we should feel free and even encouraged to take fresh approaches.
Alex
Mark Allman wrote:
>
> > > Long delay links.
> > > Links with high bandwidth-delay product.
> >
> > If all this group ends up doing is documenting the pilc
> > characteristics (including documenting existing mechanisms to
> > mitigate their effects), then I think it is fair to say that these
> > two characteristics have been handled by tcpsat. However, if
> > changes to existing protocols or developing a new protocol becomes
> > part of the charter for the group, then these two characteristics
> > should remain on the list...
>
> I think you hit it just right. I am biased and all, but I think
> tcpsat covered the documentation part just fine. And, I have not
> heard of any new mitigations that have widespread support for
> standardization, which is why the two above characteristics were
> listed as they are. There may be mechanisms that have more support
> than we realize. In that case, these items should be brought up as
> reasons to not cross the above two items off the PILC "things to
> work on" list.
>
> Thanks,
> allman
>
> ---
> http://roland.lerc.nasa.gov/~mallman/
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 09:12:19 EST