HI,
>
> I believe that was just a misunderstanding: Karen thought that I had
only
> used RFC793 when writing draft-welzl-taps-transports-00, but really I
did try
> to use all relevant RFCs.
>
[Karen Elisabeth Egede Nielsen] ......well, I did observe that you were
referring to rfc1122 (and also RFC6093).
but the result and the emphasis on the PUSH bit made me think that weight
only was put on what was written in RFC 793. ;-)
BTW, something which I didn't mention yesterday, but now got the "energy"
to in and find is the following:
Send: This sends a message of a certain length in bytes over an
association. A number can be provided to later refer to the
correct message when reporting an error and a stream id is
provided to specify the stream to be used inside an association
(we consider this as a mandatory parameter here for simplicity: if
not provided, the stream id defaults to 0). An optional maximum
life time can specify the time after which the message should be
discarded rather than sent. A choice (advisory, i.e. not
guaranteed) of the preferred path can be made by providing a
destination transport address, and the message can be delivered
out-of-order if the unordered flag is set. Another advisory flag
indicates the ULP's preference to avoid bundling user data with
other outbound DATA chunks (i.e., in the same packet). The
^^^^
handling of this no-bundle flags is similar to the sender side
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
handling of the TCP PUSH flag.
^^^^^^^^^^^^^^^^^^^^^^^^
A payload protocol-id can be
provided to pass a value that indicates the type of payload
protocol data to the peer.
Can we agree to have this be removed also :-).
Bundling in SCTP is similar to Nagle. Indeed it is often implemented as
Nagle exactly
(though with add-ons). Comparing it to PUSH is NOT helpful.
Then, there is the additional discussion about RFC4960 and RFC6458 (socket
api) in that
bundling control is not often implemented as a flag on a message, but as
in TCP on a per association/connection level.
This again made me think emphasis was put on RFC793/RFC4960 and not much
else ;-).
BR, Karen
> Cheers,
> Michael
_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps
