Subject: Re: Fw: [Tsvwg] ULP Framing for TCP

From: Stephen Bailey <[email-masked]>
Date: Wed, 13 Jun 2001 22:17:44 -0400

Jim[s],

> > So this ensures that the sender won't knowingly emit a segment with a
> > payload that will falsely match the key value?
> > What does the sender emit in this case?
> 
> The sender would revert to "b." in this case.  See below.

It could also send segments that are guaranteed not to fail false
positive.  A segment whose data length is shorter than the framing
header can not be mistaken for a properly framed segment.  This is an
alternative which will keep the data flowing.

Waiting for the ACKs to catch is my kind of solution to the infrequent
case (simple and brute force :^), but how do you know that the ACKs
have caught up?  What happens if a packet (or all the packets, if a
router is eating fragments?) gets lost?  Do you wait for the last ACK
or 2*MSL, whichever comes first?  In this strategy, when a packet DOES
get lost, do you then send PDUs up to an including the next one in the
stream which is larger than the new MSS, and wait for ACK to that
point?  In the case where you have a long stream of old MSS PDUs, you
will be sending them one at a time until you reach the end of what you
sent before you learned of the path MTU change.

I'm not saying this is a bad idea, I just want to make sure I
understand the behavior.

> > Is receiver framing behavior (out-of-order data placement) ever resumed
> > and what triggers it?

As long as the sender is always `trying' to send segments that begin
at a framing boundary, framing should be restored.  Specifically, the
sender must not cross a framed PDU boundary within a segment.  Given
that framed PDUs are delivered to the framing layer as a unit, there
will be no upper-layer demand to send less than a framed unit of data
so framing should be stable across such interruptions.

Steph

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg