[e2e] a new IRTF group on Transport Models

[Cannara]

Sally,

I'll be happy to supply some example test traces of uncongested paths with
small physical-error rates and common RTTs that together challenge present TCP
performance.  The addresses in the pkts should, of course, be anonymized.

Alex

Sally Floyd wrote:
> 
> 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.)