OK. if there're no further opinions, I will do it. -- Yoshi
On Fri, Jun 19, 2020 at 11:58 AM Martin Duke <martin.h.d...@gmail.com> wrote: > Hi Stewart, > > I'm going to ship draft-16 to the IESG today. Any last concerns beyond the > stated differences from WG consensus? > > Yoshi, please update the shepherd writeup to cover the flavor of this > discussion. > > On Thu, Jun 18, 2020 at 7:18 AM Stewart Bryant <stewart.bry...@gmail.com> > wrote: > >> Here is how we should proceed. >> >> We make as much progress as we can agree on which will clear some of the >> issue below. >> >> For any remaining issues for which you have wider consensus but where we >> cannot agree, I modify my review and the IESG decides how they wish to >> proceed. >> >> I am prepared to be in the rough but I have a duty to draw attention to >> concerns. >> >> Best regards >> >> Stewart >> >> >> > On 18 Jun 2020, at 14:32, Mark Allman <mall...@icir.org> wrote: >> > >> > >> > Last comment first ... >> > >> >> We are getting there, but I would ask that you take the transport >> >> hat off and look again from an infrastructure and packet transport >> >> perspective. >> > >> > I don't view this as looking at it from a transport >> > vs. infrastructure perspective. >> > >> > And, I am not disagreeing with your perspective. My take is that >> > the nub of what you're saying is that there are cases where we know >> > something about the network. And, that something let's us design a >> > more savvy loss detection and response scheme. E.g., because the >> > link / path is known to be short and so using an initial RTO of 1sec >> > is too long. E.g., because the cause of loss is known or can be >> > safely assumed to not be congestion. And, I think that view is both >> > correct and reasonable. >> > >> > However, ... >> > >> > (0) I do not view that view as inconsistent with this document at >> > all. >> > >> > (1) Because there are cases where we know more doesn't make a set of >> > default requirements for the general case when we don't >> > understand the path any less valid. >> > >> > (2) The document explicitly says alternates are fine modulo the >> > usual consensus. I.e., in cases where we have more information >> > we can do things differently. And, the cost of that is no >> > different than the cost today (i.e., specifying it and gaining >> > consensus). >> > >> > So, my view is that this all boils down to making it clear that this >> > is not somehow THE (best) way to do time-based loss detection for >> > all cases. Rather, following the guidelines with result in a >> > safe-for-general-use loss detector. >> > >> >> In the general case, delay across a >> >> network path depends not only on distance, but also a number of >> >> variable components such as the route and the level of buffering in >> >> intermediate devices. >> >> >> >> Its is more the contending/conflicting traffic rather than the >> >> buffering, or perhaps the time spent in queues, but “buffering” is >> >> a link a transport colloquial term. >> > >> > Per this and Gorry's note, I will tweak this to use queuing, as that >> > is what I meant. >> > >> >> Perhaps we could include a clearer disclaimer regarding the >> >> non-best-effort-internet-end-to-end traffic? >> >> You have some text on this down in section 2 but it is a bit buried. >> > >> > OK, let me see if I can foreshadow this a bit more and/or pull some >> > from section 2 to earlier. >> > >> >> An exception to this rule is if an IETF standardized mechanism >> >> determines that a particular loss is due to a non-congestion >> >> event (e.g., packet corruption). >> >> >> >> That is a bit heavy. It should be “a protocol” there than an IETF >> >> standardarized mechanism. The IETF does not have a monopoly on >> >> pre-blessing protocols before they are deployed. >> >> [...] >> >> >> >> In some cases you cannot tell the cause, but it is more important >> >> to ignore the loss. OAM being a particularly good example. >> > >> > First, I don't think I can readily change this without going against >> > the consensus the document has already gathered. (I.e., this is not >> > about the intro, framing, context, etc. bits, but the actual meat of >> > the technical stuff.) >> > >> > Second, you are right that the IETF does not have a monopoly, but >> > that doesn't make the statement in the document the wrong thing to >> > say. >> > >> > Third, I doubt I should change it. The problem here from the >> > standpoint of a set of default guidelines is that we'd like a >> > mechanism to determine the cause of loss to **actually work** before >> > it's OK to avoid a congestion control response. If a standardized >> > mechanism is used then we have some confidence that the mechanism >> > has been vetted as reasonable. If the mechanism is not standardized >> > then we have no idea if it actually works or if it is some >> > ill-conceived scheme that is badly broken. In this latter case, I >> > don't think we want to bless this approach as OK within the default. >> > It may be OK, but it should get some consensus that it is OK. >> > >> > allman >> >>
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
