[{"author": "Christian Huitema", "text": "

For some reason, Michael does not show in the Meetecho list of participants...

", "time": "2022-11-09T13:06:41Z"}, {"author": "Yoshifumi Nishida", "text": "

ok. thanks for notifying

", "time": "2022-11-09T13:07:26Z"}, {"author": "Lorenzo Miniero", "text": "

Which Micheal are you referring to, Christian?

", "time": "2022-11-09T13:08:36Z"}, {"author": "Christian Huitema", "text": "

Michael Tuexen

", "time": "2022-11-09T13:09:06Z"}, {"author": "Lorenzo Miniero", "text": "

Is he in the room or remote? If in the room, he may have to scan the QR code again for the onsite tool

", "time": "2022-11-09T13:11:58Z"}, {"author": "Yoshifumi Nishida", "text": "

he is in the room and in the chair seat.

", "time": "2022-11-09T13:18:03Z"}, {"author": "Mirja K\u00fchlewind", "text": "

the option registry is actually standards action or iesg approval but we do have exp options in there\u2026

", "time": "2022-11-09T13:20:52Z"}, {"author": "Christian Huitema", "text": "

Question: What happens if the path capabilities change during the connection, e.g., negotiate acc ECN, then after some time routing changes and ECN is washed?

", "time": "2022-11-09T13:32:45Z"}, {"author": "Lars Eggert", "text": "

there is no qr code shown in the room, so it's a bit more work to join, which means some won't bother

", "time": "2022-11-09T13:34:36Z"}, {"author": "Yoshifumi Nishida", "text": "

christian, are you going to ask it?

", "time": "2022-11-09T13:34:50Z"}, {"author": "Yoshifumi Nishida", "text": "

ok. I see you are in the queue

", "time": "2022-11-09T13:35:26Z"}, {"author": "Christian Huitema", "text": "

yes

", "time": "2022-11-09T13:35:26Z"}, {"author": "Christian Huitema", "text": "

Yes, Gorry, I will review the draft

", "time": "2022-11-09T13:41:34Z"}, {"author": "Christian Huitema", "text": "

Sound is sometimes breaking terribly for me. Is this just my problem?

", "time": "2022-11-09T13:44:22Z"}, {"author": "Jonathan Morton", "text": "

I think it's clipping, but otherwise fine

", "time": "2022-11-09T13:45:00Z"}, {"author": "Christian Huitema", "text": "

To Ian: in my implementation of BBR, I actually replaced the BBR start by Hystart++, and it worked better.

", "time": "2022-11-09T13:46:59Z"}, {"author": "Christian Huitema", "text": "

Sorry for leaving the queue abruptly. My connection broke.

", "time": "2022-11-09T13:55:28Z"}, {"author": "Christian Huitema", "text": "

To Martin: should this be done in CONGRESS?

", "time": "2022-11-09T13:56:38Z"}, {"author": "Christian Huitema", "text": "

Please someone say CONGRESS?

", "time": "2022-11-09T14:00:09Z"}, {"author": "Christian Huitema", "text": "

Because QUIC too!

", "time": "2022-11-09T14:00:28Z"}, {"author": "Jonathan Morton", "text": "

it's been mentioned

", "time": "2022-11-09T14:00:31Z"}, {"author": "Christian Huitema", "text": "

My connection is terrible today. Sorry.

", "time": "2022-11-09T14:01:25Z"}, {"author": "Mirja K\u00fchlewind", "text": "

I relayed your proposal to the mic.

", "time": "2022-11-09T14:02:19Z"}, {"author": "Jonathan Morton", "text": "

additional case for TARR: when the path needs to aggregate packets to utilise scarce TXOPs, eg. modern wifi

", "time": "2022-11-09T14:02:57Z"}, {"author": "Christian Huitema", "text": "

Thanks, Mirja

", "time": "2022-11-09T14:03:00Z"}, {"author": "Michael Welzl", "text": "

Stupid question, why couldn't we re-use the push bit for this (TARR)? It's otherwise useless except at the end of a connection, where one will want an immediate ACK anyway

", "time": "2022-11-09T14:04:50Z"}, {"author": "Christian Huitema", "text": "

On TARR: if we do something for controlling ack rate in TCP, should we try to keep common concepts with the delayed ack option in QUIC? This would help building common experience, etc.

", "time": "2022-11-09T14:05:27Z"}, {"author": "Jonathan Morton", "text": "

PSH is still useful in application limited cases, where the receiving application needs to receive data from the socket promptly rather than waiting for a full buffer

", "time": "2022-11-09T14:05:43Z"}, {"author": "Jonathan Morton", "text": "

that's what PSH is used for, not to elicit an immediate ACK

", "time": "2022-11-09T14:06:11Z"}, {"author": "Jonathan Morton", "text": "

perhaps Yoshi should relay Christian's questions for the rest of the session

", "time": "2022-11-09T14:07:37Z"}, {"author": "Christian Huitema", "text": "

If someone could, that would be nice

", "time": "2022-11-09T14:08:57Z"}, {"author": "Mirja K\u00fchlewind", "text": "

I will

", "time": "2022-11-09T14:09:33Z"}, {"author": "Yoshifumi Nishida", "text": "

oh thx. Mirja

", "time": "2022-11-09T14:10:01Z"}, {"author": "Michael Welzl", "text": "

(answering myself) - of course, some hosts now set PSH=1 all the time, and then such re-purposing would just disable Delayed ACKs whenever receivers are updated but senders are not... this could get ugly for a while :)

", "time": "2022-11-09T14:10:43Z"}, {"author": "Michael Welzl", "text": "

@Jonathan Morton I understand that's not the purpose but... with modern APIs, it becomes unnecessary. I'm in a camp that wants to deprecate sockets :-)

", "time": "2022-11-09T14:12:14Z"}, {"author": "Jonathan Morton", "text": "

it seems to be a very common misconception that PSH elicits an immediate ACK at the wire protocol, whereas it was actually intended to immediately deliver buffered data to the receiving application

", "time": "2022-11-09T14:13:56Z"}, {"author": "Jonathan Morton", "text": "

@Gomez: you may wish to internalise this an an FAQ for future use

", "time": "2022-11-09T14:14:43Z"}, {"author": "Jonathan Morton", "text": "

or even provide a brief explanation as to why PSH is not used for this in the draft

", "time": "2022-11-09T14:15:26Z"}, {"author": "Michael Welzl", "text": "

Maybe I missed something, but did someone but me talk about PSH? I didn't want to stir up trouble with that suggestion :)

", "time": "2022-11-09T14:16:26Z"}, {"author": "Jonathan Morton", "text": "

there was someone asking in the room about it and being rather insistent, so I stepped in to provide a \"brief answer\"

", "time": "2022-11-09T14:17:12Z"}, {"author": "Richard Scheffenegger", "text": "

Hmm.. .a TCP flag for one-time use in SYN...?

", "time": "2022-11-09T14:18:44Z"}, {"author": "Yoshifumi Nishida", "text": "

it's in FYN.

", "time": "2022-11-09T14:19:04Z"}, {"author": "Michael Welzl", "text": "

Anyway, I stand by my statement: it's a useless function, it should be deprecated, ideally along with the idea of actively having to query for data. It's even also optional to implement support for it in an API today, both on the sender and receiver side, according to RFC 1122 (though I didn't check if 793bis changes that)

", "time": "2022-11-09T14:19:11Z"}, {"author": "Yoshifumi Nishida", "text": "

oh. sorry I misled your question > richard.

", "time": "2022-11-09T14:19:44Z"}, {"author": "Jonathan Morton", "text": "

A TCP MAY implement PUSH flags on SEND calls. If PUSH flags
\n are not implemented, then the sending TCP: (1) must not
\n buffer data indefinitely, and (2) MUST set the PSH bit in
\n the last buffered segment (i.e., when there is no more
\n queued data to be sent).

\n
        The discussion in RFC-793 on pages 48, 50, and 74\n        erroneously implies that a received PSH flag must be passed\n        to the application layer.  Passing a received PSH flag to\n        the application layer is now OPTIONAL.\n
", "time": "2022-11-09T14:24:49Z"}, {"author": "Jonathan Morton", "text": "

note the distinction between \"PUSH flag\" (host API) and \"PSH bit\" (wire protocol)

", "time": "2022-11-09T14:25:23Z"}, {"author": "Jonathan Morton", "text": "

At the receiver, the PSH bit forces buffered data to be
\n delivered to the application (even if less than a full
\n buffer has been received). Conversely, the lack of a
\n PSH bit can be used to avoid unnecessary wakeup calls
\n to the application process; this can be an important
\n performance optimization for large timesharing hosts.

", "time": "2022-11-09T14:26:11Z"}, {"author": "Jonathan Morton", "text": "

I read that as the PSH bit handling still being mandatory

", "time": "2022-11-09T14:26:55Z"}, {"author": "Jonathan Morton", "text": "

but a PUSH flag facility in a host API being optional

", "time": "2022-11-09T14:27:15Z"}, {"author": "Lars Eggert", "text": "

so we discussed these differences when we did 9002 and the differences are deliberate

", "time": "2022-11-09T14:28:53Z"}, {"author": "Richard Scheffenegger", "text": "

@Jonathan: Still no advise to have a PSH bit trigger an immediate ACK (which some stacks do, nevertheless)

", "time": "2022-11-09T14:29:07Z"}, {"author": "Richard Scheffenegger", "text": "

@Jonathan: Still no advise to have a PSH bit trigger an immediate ACK (which some stacks do, nevertheless)

", "time": "2022-11-09T14:29:17Z"}, {"author": "Jonathan Morton", "text": "

yes, that was my earlier point

", "time": "2022-11-09T14:29:23Z"}, {"author": "Jonathan Morton", "text": "

PSH bit immediately deliveres bufferes data to the application, and does not guarantee any other effect

", "time": "2022-11-09T14:29:58Z"}, {"author": "Richard Scheffenegger", "text": "

TARR seems to be a more universal approach, rather than changing the fine semantics of the PSH bit in the TCP header :)

", "time": "2022-11-09T14:30:52Z"}, {"author": "Jonathan Morton", "text": "

Michael Welzl suggests that even the immediate delivery was optional

", "time": "2022-11-09T14:30:57Z"}, {"author": "Jonathan Morton", "text": "

but I think he has misread RFC-1122

", "time": "2022-11-09T14:31:11Z"}, {"author": "Jonathan Morton", "text": "

so I definitely support this feature in TARR, and merely suggest that this misconception about the PSH bit be summarised in the text

", "time": "2022-11-09T14:32:25Z"}, {"author": "Michael Welzl", "text": "

@Jonathan Morton yeah, that's what i said, optional in the API

", "time": "2022-11-09T14:33:08Z"}, {"author": "Jonathan Morton", "text": "

what's optional on the receive side is only explicitly relaying the PSH bit status as a PUSH flag

", "time": "2022-11-09T14:33:46Z"}]