Subject: [Tsvwg] RE: [rdma] Fragmentation functionality

From: "Douglas Otis" <[email-masked]>
Date: Sun, 24 Mar 2002 20:10:02 -0800

Amir,

Any and all.

Propose a change to RFC 2960, that is a choice.  Perhaps redefine the SSN as
that represents two bytes not used rather the one byte saved by a Data Chunk
flag redefinition.  It is a choice to require message reassembly buffering
as well.  David has mischaracterized the function of the SCTP-DDP shim as it
includes fragmentation to implement the DDP Header extension.  It would
appear you have David Black's confusing blessing however.  Good luck with
your changes to SCTP.

Doug

On March 24, 2002 6:53 PM Amir Shalit ([email-masked]) wrote:
>
> Doug,
>
> First, I fail to see the SCTP change you
> are avoiding using a DDP shim.
>
> Second, considering very limited (if any) SCTP
> deployment, expanding RFC2960 is a valid option.
>
> Amir
>
> --- Douglas Otis <[email-masked]> wrote:
> > David,
> >
> > I would expect you to advocate a transport change,
> > even after more than year long opportunity.  The
> > SCTP-DDP shim does fragmentation and not the ULP
> > above it.  That point should be clear.
> >
> > Your flag redefinition does not introduce Tag,
> > Offset, Immediate Data, etc. for RDMA as example.
> > So you wish to rewrite RFC 2960.  I think a shim
> > proposal that does not disrupt RFC 2960 is a better
> > approach myself and was the purpose of the shim
> > negotiation.  Then again you also thought it was a
> > good idea to redefine the TCP Urgent Pointer and
> > then introduce FIM in TCP applications as a price
> > to pay.  Least to say, not changing RFC 2960 offers
> > the opportunity to introduce DDP without disruption.
> >
> > Offering SCTP or SCTP-DDP in hardware does not
> > require a lengthy renegotiation of RFC 2960 and will
> > be beneficial to all mentioned protocols.  Unless
> > your desire is to hinder development, do not
> > consider a transport change.
> >
> > Doug
> >
> > On March 24, 2002 4:23 PM David Black
> > ([email-masked]} wrote:
> > >
> > > > Allowing the application to perform
> > > > fragmentation has been a long held and advocated
> > > > solution to this problem.
> > >
> > > Then allow me to dis-advocate that solution.  None
> > > of the protocols I mentioned in my ROI
> > > presentation (iSCSI, NFS, CIFS) in Minneapolis
> > > want to be responsible for fragmentation to PMTU
> > > size or for coping with PMTU changes, and I'm
> > > sure that there are lots more.  That's a
> > > high price to pay for use of DDP.  IMHO, Doug's
> > > shim needs to replace the fragmentation
> > > functionality that it disablesin SCTP so that
> > > SCTP+DDP can deal with arbitrary length ULP
> > > messages.
> > >
> > > If SCTP were fragmenting, the B and E flags would
> > > take care of this - replacing those flags with
> > > DDP flags would solve most of this problem,
> > > but there are details to work out (e.g., the
> > > existing 3 DDP flags need to be consistent across
> > > a fragmented ULP message -
> > > making them valid only when the DDP version B bit
> > > is set would be one approach).
> > >
> > > --David
> > >

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