> On 5. nov. 2015, at 00.02, Karen Elisabeth Egede Nielsen 
> <[email protected]> wrote:
> 
> 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.

Agreed. Actually I think that was not by intention, just a nit that happened as 
I wrote it: I don’t think I wanted to compare it with PUSH but indeed with 
Nagle.


> 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 ;-).

Things like “[not] often implemented” really shouldn’t be there. All mistakes, 
all to be fixed. Apologies!

Michael

_______________________________________________
Taps mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/taps

Reply via email to