[e2e] a new IRTF group on Transport Models

[Sally Floyd]

Frank -

>Is there any thought to identifying information
>that routers and end systems might provide that
>either can be fed back into the models to refine
>them or used in parallel to (in)validate them?
>
>A simple example might be packet drops. If models 
>assume that the only reason packets are dropped is
>overflowing queues due to congestion, that leads to
>certain conclusions, etc, and tweaking our transport
>protocols in a certain direction. But if it turns
>out that a significant percentage of packet drops
>is because of something else, then that conclusion
>would be incorrect...

Certainly, any evaluation of transport protocols or of congestion
control mechanisms needs to take into account the difference between
packets dropped due to congestion and packets dropped due to some
other reason (e.g., corruption).  In simulations, non-congestion-related
packet drops are only present when explicitly introduced, and in
test beds, I assume that there are mechanisms to detect and report
on the different types of packet drops.  And in analysis, it is
important to consider the possibilities of non-congestion-related
packet losses.

If you are asking if there has been any thought to proposing additions
to the protocol suite to report such information, the short answer
is that this is not intended to be the province of the Transport
Models Research Group (TMRG).  The proposal is that TMRG itself
would *not* be proposing changes to transport protocols or to
explicit communication between transport protocols and lower layers,
but would *only* be concerned with improving our methodologies for
evaluating such proposals.  E.g., with test suites for simulations
or for test beds, discussions of topologies and traffic generation,
of the models underlying our analysis, etc.

- Sally
http://www.icir.org/floyd/

Addendum:
I am personally very interested in the potential benefits (and
complications) of more explicit communication between link layers
and transport protocols, and in particular I like the idea of
explicit communication from lower layers to transport saying "the
packet with this packet header was dropped due to corruption".  It
is not clear to me yet exactly what the response of the transport
protocol should be to reports of packet corruption, however -
continuing to send at a high rate in the face of a high rate of
packet corruption doesn't sound too appealing.  And there are
complications with other forms of explicit communication between
link layers and transport protocols as well, e.g., as discussed in
the IAB internet-draft on "Architectural Implications of Link
Indications", at
"http://www.iab.org/documents/drafts/draft-iab-link-indications-01.txt".

It might be that it is time also for a research group on Explicit
Communication between Transport Protocols and Lower Layers, but
someone else will have to start it.  (I believe that there is already
a proposal in the works for a new research group on new congestion
control mechanisms, which includes one class of proposed new forms
of explicit communication between transport protocols and routers.)