search

ietf-tapswg / api-drafts

Architecture, interface, and implementation drafts for the definition of an abstract API for IETF TAPS
Other
24 stars 15 forks source link

Wording of receiver backpressure. #1387

Closed mwelzl closed 1 year ago

mwelzl commented 1 year ago

Closes #1283. May become unnecessary though, depending on what we think of #1352.

gorryfair commented 1 year ago

I agree with the NEW text - HOWEVER, I am not sure this describes back pressure yet. I suspect we ought to talk also about the opposite case, e.g.,:

"An application that is temporarily unable to process received events for a connection, could leave these pending actions in the queue . This leads to a build-up of unread data, which, in turn, could result in back pressure on the sender by the transport protocol (e.g., restricting transmission of new data by the sender using the TCP rand or QUIC flow credit mechanisms).

mwelzl commented 1 year ago

So this is about a more local form of backpressure - as the text says, the application can give backpressure to the stack below, to limit the number of events that it will see. In my opinion, that's already clear enough?

As for bringing in flow control (for protocols that do it) - In my opinion, discussing this here just makes it more complicated?

gorryfair commented 1 year ago

I would prefer if you hinted at what "provide backpressure to the transport stack" means to the transport services implementation, although quite agree if one tries to give protocol examples, it's too much....