Subject: RE: [rddp] Alignment and TCP modification

From: "Williams, Jim" <[email-masked]>
Date: Tue, 7 Jan 2003 10:10:16 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]

> > > So, I believe the primary issue before the WG is whether 
> > > to accept:
> > > 	- The RDDP protocols must allow implementations over
> > > 		unmodified TCP/IP stacks.
> > > as a requirement.
> > 
> > I don't believe anyone has proposed or recommended otherwise.
> > (MPA states an MPA-aware sender SHOULD align, but even that
> > is not contradictory to the above.)
> > [...]
> 
> The point is that "optional" (MAY) is a considerably weaker
> requirement than SHOULD (see RFC 2119).  I believe that an
> unmodified TCP stack cannot comply with a "SHOULD align"
> requirement solely on the basis that the an implementer does
> not want to or cannot modify the stack, in contrast to a
> "MAY align" requirement.

If a sender MAY be MPA-aware, and an MPA-aware sender
SHOULD align, then we have an overall MAY.  This was how
I interpreted the draft.  However, your
point is well taken, and the draft could be a bit
clearer on this.

> [...]
> 
> 
> Markers and similar mechanisms are among the ways to obtain direct
> placeability of unaligned RDDP PDUs [...].

The data can't be placed until the header is received.  In the
unaligned case, at best only part of the data can be placed, even
with markers or similar mechanism.

Doing partial packet placement, while theoretically possible,
has some serious practical concerns.

  1. To be of any value, it implies the ability to free partial
     buffers for re-use, while keeping the unplaced data.
     Or else copying the unplaced fragment elsewhere to allow
     freeing the buffer.  Either causes serious implementation
     complexities that are avoided in the aligned case.

  2. Since each supported connection may have an associated
     unplaced fragment, the total data buffering required
     now scales linearly with the number of active connections.
     This is fundamentally different than the aligned case.
     Worse, if there are multiple gaps, there may be 
     multiple unplaced fragments on a single connection.

I do not believe that direct placement of unaligned PDUs 
achieves the objectives that the proponents of direct
placement are looking for.

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

---

From: "Vadim Makhervaks" <[email-masked]>
Date: Tue, 7 Jan 2003 17:49:41 +0200

inline

|---------+---------------------------->
|         |           "Williams, Jim"  |
|         |           <Jim.Williams@emu|
|         |           lex.com>         |
|         |           Sent by:         |
|         |           [email-masked]|
|         |           rg               |
|         |                            |
|         |                            |
|         |           07/01/03 05:10 PM|
|---------+---------------------------->
  >-------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                               |
  |       To:       [email-masked]                                                                                                 |
  |       cc:                                                                                                                     |
  |       Subject:  RE: [rddp] Alignment and TCP modification                                                                     |
  >-------------------------------------------------------------------------------------------------------------------------------|

<VM> I would say that the data cannot be placed until the entire MPA
segment has been received. Even in-order reception of part
of MPA segment would require to keep the received part in the intermediate
buffers <VM>

<VM> I don't think that purpose of Markers is to enable direct data
placement.
Markers just help to find the next DDP header. This feature is very
valuable when TCP segment is lost.
In aligned case Markers allow to ensure alignment and perform direct data
placement.
In not aligned case, Markers reduce the size of the intermediate buffers -
placement of the arriving DDP segments can be done without waiting for the
lost segment.
Another feature of Markers, is their transparency to the resegmenting TCP
boxes. <VM>

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 8 Jan 2003 11:30:46 -0600

On 1/7/03, Vadim Makhervaks replying to Jim Williams wrote:

>The data can't be placed until the header is received.  In
>the unaligned case, at best only part of the data can be
>placed, even with markers or similar mechanism.
>
><VM> I would say that the data cannot be placed until the
>entire MPA segment has been received. Even in-order
>reception of part of MPA segment would require to keep the
>received part in the intermediate buffers <VM>
>
><VM> I don't think that purpose of Markers is to enable
>direct data placement. Markers just help to find the next
>DDP header. This feature is very valuable when TCP segment
>is lost. In aligned case Markers allow to ensure alignment
>and perform direct data placement. In not aligned case,
>Markers reduce the size of the intermediate buffers -
>placement of the arriving DDP segments can be done without
>waiting for the lost segment. Another feature of Markers,
>is their transparency to the resegmenting TCP boxes. <VM>

Markers enable detection of the DDP segment even when
delivered out-of-order. This is true even when alignment has
not been preserved, its just that two (or possibly more) TCP
segments will have to be received to get the DDP segment.
But placement is still enabled even if a prior TCP segment
holding portions of prior DDP segments is still missing.

Consider the very common scenario where there are many DDP
segments in-flight, and only a single segment has been
dropped. Even without alignment, nearly every DDP segment
can be found and placed.

The worst case scenario without alignment does indeed
require extensive buffering (theoretically up to half of
what a non-marker solution would require). But as previosly
discussed, it would be a totally valid implementation
decision to handle such a worst case scenario on the host
processor. The protocol works even without hardware
optimization of worst case scenarios.

Most importantly, the effort required to support
non-alligned connections does not have to have any adverse
effect on the alligned connections.

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

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 8 Jan 2003 11:46:31 -0600

>     now scales linearly with the number of active 

It scales linearly with the number of active unaligned
connections. No additional buffering is required for aligned
connections.

Whether the wording is MAY or SHOULD, the intent is clear
that anyone intending to make extensive use of DDP/MPA/TCP
really needs to do alignment, and to ensure that their
traffic is not routinely trounced by a middlebox that will
destroy that alignment.

It is my opinion that the vast majority of connections in
the overwhelming majority of deployments will originate and
maintain alignment. Relatively low cost hardware can
optimize an amazingly large number of these connections.
This is of great value to the end user, whether or not we
can guarantee that any specific connection will be aligned.

An implementation can limit the amount of buffering it
wishes to allocate to support unaligned reception. This can
be in the form of a limit on RNIC buffering, or in simply
passing them to the host to handle (and hence limiting
support to the host's capacity).

This means that an RNIC will have to rate itself based on
the maximum number of concurrent aligned connections and
unaligned connections that it can support. It is under no
obligation to divert an unlimited portion of its resources
to support unaligned connections.

Caitlin Bestler