Subject: RE: [rddp] Let's discuss markers

From: David Borman <[email-masked]>
Date: Tue, 3 Dec 2002 16:15:00 -0600 (CST)

> From: Parag Bhide <[email-masked]>
> Subject: RE: [rddp] Let's discuss markers
> Date: Tue, 3 Dec 2002 13:44:54 -0800 
>
> URG pointer seems like a good idea except,
>
> 1. (I agree with Somesh) TCP receives keeps only one URG pointer value
> ("latest as defined by RFC 793). While what we need is URG pointer
> associated with each packet.

The URG bit + SEG.URG is the per-packet Urgent pointer.  RCV.URG is the
cumulative urgent pointer kept by the TCP state machine.  When processing
out-of-order TCP segments, URG bit + SEG.URG is what is of interest, not
the TCP state machine.

> 2. When DDP segments are carried in different packets (alignment problem at
> the sender or middle-box) it could result in TCP packets without any URG
> pointer.  These are the packet that will carry the second half of the DDP
> segment. (Note that URG pointer can point only to future seq# and when the
> packet was created there may not be another DDP segment available following
> this segment submitted to TCP layer).

Yes, that is exactly how it should work.  The packet that actually
contains the DDP header is the only one that needs the URG bit for
out-of-order processing.  The packet without the DDP header may still
have the URG bit and an Urgent pointer, but in that case it had better
be true that:
	SEG.SEQ + SEG.UP > SEG.SEQ + SEG.LEN
i.e, it points beyond the current packet.

> These will not be possible w/o changes in TCP.

TCP is already being changed if out-of-order processing of TCP segments
is being allowed.

		-David Borman, [email-masked]
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp

---

From: Caitlin Bestler <[email-masked]>
Date: Tue, 3 Dec 2002 17:03:01 -0600

On 12/3/02, David Borman wrote:

>> 1. (I agree with Somesh) TCP receives keeps only one URG
>> pointer value ("latest as defined by RFC 793). While
>> what we need is URG pointer associated with each packet.
>
>The URG bit + SEG.URG is the per-packet Urgent pointer. 
>RCV.URG is the cumulative urgent pointer kept by the TCP
>state machine.  When processing out-of-order TCP segments,
>URG bit + SEG.URG is what is of interest, not the TCP
>state machine.
>

You are assuming that middle-boxes are workig one TCP
segment at a time. It is an excellent strategy, but not the
only one available.

A middlebox may reconstitute a new stream based upon the
semantics delivered to it as a local TCP consumer. That
would mean compression of urgent pointers and loss of the
critical information.

This sort of reconstitution, especially with associated
middle-box buffering, can be valuable when bridging between
very disimiliar networks. I prepared an evaluation of
exactly that sort of stream rebuilder for a pre-DOCSIS
upstream relay over cable TV plants. The cost of obtaining
permission to do a sustained upstream burst was so high that
it made sense to either send little burstlets, or to hold
upstream data for larger transmissions. I think we can be
confident that there is at least one middle-box  out there
that had similiar reasons to reduce and reconstitute a TCP
stream.

Caitlin Bestler
http://asomi.com/CaitlinBestler/
_______________________________________________
rddp mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rddp