Re: [tcpm] Is this a problem?

[Ted Faber <[e-mail]>]

On Wed, Nov 21, 2007 at 09:23:47AM -0500, Ethan Blanton wrote:
> Lloyd Wood spake unto us the following wisdom:
> > At Tuesday 20/11/2007 20:11 -0500, Ethan Blanton wrote:
> > >Joe keeps making this point because it is _very important_.  Any
> > >feature which can be accomplished at Layer N can be accomplished at
> > >Layer N - 1, and vice-versa.  
> > 
> > One obvious exception: end-to-end reliabililty.
> > 
> > Another: error-coding for the channel.
> 
> Not to digress, but ... I think this makes the argument beautifully.
> Either of these *can* be handled at any layer, but we obviously agree
> that it's a Bad Idea to push these all the way down to the MAC layer.
> There is nothing magical about layering, that says "a protocol can
> only work if layered".  Separation of concerns simply makes the model
> easier to grasp, and easier to Get Right.
> 
> We could do end-to-end flow control, reliability, and link
> error-coding all in Layer 1 (or Layer 2, depending on which way you
> want to push), but we don't, and for a very good reason.

[hat off]

I think that any layer that can accomplish end-to-end reliability is
a transport layer by definition.

A link layer capable of end-to-end retransmission (say) is inherently
reaching beyond the link.  You could call such a layer a link layer, but
the presence of an end-to-end mechanism makes it a transport layer to
me.

I actually think your functionality statement is a little backward -
anything you can do at layer N, you can do above at layer N+1.  That's
because the information to implement the new feature is potentially
available from the lower layers.  An application can implement
end-to-end reliability because the end-to-end structures/concepts are
created by the transport.

Implementing at layer N+1 also assumes that there's no implementation of
the functionality at layer N that will interfere with your design.
Implementing a retransmission strategy above TCP is fraught with peril.

Perhaps that's a way to reframe this discussion.  It's possible to
constrain TCP to provide this timer.  Are we sure that it's worth it in
terms of additional complexity in TCP and constraints on other
application resource management strategies?

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG

_______________________________________________
tcpm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tcpm