Notetaker: Richard Scheffenegger
Mirja: The [AccurateECN] document is even older with first ideas even
during ConEx.
Richard: Like the nomenclature change in the latest revision.
Mohit: Agree with good change in terminology. We have implemented the
new draft in the ns-3 simulator. People are free to test and use this.
Gorry: Who has implemented this in code?
Richard: FreeBSD has the core concept of this draft for ~3 years now.
Neal: Linux has something very close since ~10 years now.
Michael: Some implementation use SYN Cookies - would be useful if
clients use this option on the final ACK of the 3WHS.
Charles: Can describe this in the document.
Stuart: Document is going on for long, thank you - quite useful. It's
useful for constrained devices as well. I think it's time for WGLC.
Yoshi: Read recent version of the draft, good shape. Middlebox issue -
paths can change in the middle of the session. In some cases the the
final path may not support TARR - on retransmitted packets, you need to
attach the option, but this may prevent the packet from getting through.
Have you considered this?
Charles: Document does not state that you need to add the TARR option on
retransmissions.
Yoshi: Current draft states it MUST include the option.
Charles: Will revisit this.
Michael: I think the suggestion are not only editorial. I think would be
simpler to get the changes in first and then do the WG last call.
Stuart: Agree with Michael - otherwise you may get the same questions
during the WGLC.
Gorry: Ask for people to actively review the document. Is it helpful to
ask the WG to actively read through.
Charles: No recent full reviews received from the WG, would be helpful.
Neal: Remind us if there are any implementations of this,
Charles: Prototype in FreeBSD by Michael, not sure of other efforts.
None that I'm aware of.
Yoshi: Neal are you interested to implement this?
Neal: Would be worthwhile - small cwnd case would be a good to have this
when the congestion window is only a handful of packets.
Yoshi: Who can review the current version of the draft?
Mohit: From ITK, I will review the document.
Michael: Also will review it.
Richard: Need wider public internet testing - to validate that RSTs with
a payload are not blocked or cause unexpected effects. Precent of having
human readable stings for the encoding, not sure if more is needed when
capturing packets and decoding from a trace.
Michael: Regarding the Encoding - wouldn't it be good enough to have a
32bit entity and IANA registry to encode states on a
first-come-first-serve basis? Also, is this intended to be presented to
the application? How would the application get this reason.
Mohamed: Should be sent to the application as this is intended for
debugging purposes.
Michael: Please think about this aspect.
Gorry: Security considerations are my highest concern, eg. SHOULD NOT
disclose any privacy information. Shouldn't this be a MUST NOT?
Mohamed: If its only the technical information there is no privacy
concerns, but will consider this more.
Gorry: Why having 256 bytes?
Mohamed: For a human readable string. Just for testing and
experimenting. We can discuss on that as we further develop this.
Michael: Yes, it is about API. In case of SCTP we defined the socket API
for the protocol. Important for portability. The IETF can work on this,
thanks for bringing this here.
Collin: We have been defining APIs for decades. Claiming the IETF didn't
is nonsense.
Yoshi: I'm wondering if we want to define the algorithm as well so that
different platforms can behave the same way.
Stuart: We want to define the abstract API - the concept should be
uniform. The behavior should be similar across platforms and protocols.
The draft currently advocates for defining the backlog in time, not in
bytes. Such that application can start working on next batch of data in
time. On the network side there needs to be some predictions. Right now
there is no prediction. Some prediction is better than none at all. This
can be affected by ACK, pacing, TARR, many factors which go into when we
think we run out of data to send. For portable code, it doesn't help if
the application behavior is different on the various platforms. You can
not build an App that has low latency, when it does not have any
visibility. In case of TCP_NOTSENT_LOWAT, Linux has a the socket
option with the same name, as MacOS, but different behavior. So, even if
it would not be perfect but better to have it.
Ingemar: I support this work. Is there benefit for the application when
the socket becomes idle frequently.
Stuart: Good suggestion - we should discuss this on the list. Goal is
that the socket should never become idle. If capacity is available,
should be used for work. If this happens frequently, the application may
have its calculations wrong. In my example we had 2 sec of buffering.
Getting this down to 1/4 sec its much better, no need to go after
perfection.
Yoshi: What is the next step at the next IETF?
Stuart: People engage on the mailing list, file issues on github. Will
decide before the next IETF what to do next. For now I focus on the
technical aspects, not to get derailed by politics. With concrete
proposals in the draft, then we need to look where to bring this work.
Anyone with an opinion please join the mailing list on sbm@ietf.org.
Martin: I agree with you - it should not return 0.
Yoshi: Also agree, should not be zero. What is the benefit of any
non-zero value for n? What is the benefit?
Michael: Application knows if final data is acked by the peer.
Yoshi: Yes, I understand it, but would like to understand the benefits
to wait for 1 secs or 2 sec for this. Do you see any useful ways in it?
Michael: Just out of curiosity .
Richard: Is this IETF work?
Michael: No...