Joel M. Halpern <jmh(_at_)joelhalpern(_dot_)com> wrote:
Having discussed TCP Congestion behavior with the TCP folks, and tried
to understand the issues, it seems to be very hard.
True -- most of us mis-understand congestion control in TCP. :^(
And if the AD is not well-versed in it, there is a serious issue.
You're in danger of limiting the field to maybe a dozen academic
types in the entire world. I suggest a lower bar.
Folks are experimenting in congestion metrics all over the place:
I doubt there is even one person in the world who understands _all_
of them.
IMHO, it's important to understand congestion-collapse and hysteresis
in feedback systems. A smattering of delay-based inferring of congestion
would be helpful if it gives insight into their weaknesses.
It's worth noting that there is an Internet Research Group on
congestion control, charged to investigate the safety of congestion
control proposals. Fortunately they don't have to report very often --
these _are_ experts, and they find it hard.
It seems to me that unless we restructure the entire way the IESG
operates (maybe a good idea, but a VERY different question) the AD
needs to have significant understanding of the technical questions
of his area.
One would hope that each AD's knowledge of the area grows...
Otherwise, the AD gets a directorate review calling out congestion
problems. He puts in the discuss. And can not discuss it with the
other ADs.
Joel listens to most IESG telechats. He knows that discussion of
the technical details of congestion control is rare!
It is not his discuss. He can not work out how to resolve it.
I must disagree! If he knows _who_ understands the issue, he can
suggest particular folks to work it out in email. That is how the
complicated issues tend to get resolved anyway.
Directorates are critical. I would hope tat all areas can move to a
situation where finding the issues rests primarily with the
directorates. But the AD has to have enough details in his area to
deal with it.
_Just_ enough -- yes.
====
I'd like to introduce the actual "requirements", from:
https://www.ietf.org/group/nomcom/2012/iesg-requirements
] TRANSPORT AREA
] --------------
]
] The Transport Area works on mechanisms related to end-to-end data
] transport as well as technologies for network storage and peer-to-peer
] applications. Transport protocols support Internet applications and
] services that exchange potentially large volumes of traffic at
] potentially high bandwidths.
]
] Together, the two Transport ADs are expected to understand how transport
] technologies (layer 4) interact with IP layer technologies and protocols
] (layer 3) technologies, and with the end-to-end aspects of various
] applications and application-layer protocols (layer 7).
Up to here, we're pretty safe, though we're entering an area where
jitter is a significant interaction, and that area is not well understood
yet.
] A Transport AD should have a good understanding of core end-to-end
] transport topics such as congestion control, flow control, real-time
] transport protocols, NATs, firewalls.
Interaction of transport with real-time applications is a black art.
The folks who understand it best say that separate queues for bulk
and real-time traffic are needed. Alas, we have no way to require them.
] These include mechanisms to detect and react to congestion in the
] Internet, such as the congestion control algorithms in transport
] control protocols such as TCP, SCTP, MPTCP, and DCCP,
"Such as" may be a saving grace here -- few folks have worked with
all of these.
] as well as congestion management schemes such as CONEX.
ConEx really doesn't belong here. The WG participants barely
understand it.
] Some topics in transport mechanisms have strong ties to the research
] community, therefore some research background can be very helpful.
Hmm... What is the NomCom supposed to _do_ about this?
] A Transport AD should also understand how transport layer technologies
] and protocols, such as NATs and firewalls,
Not all of us consider these legitimate "transport layer technologies"
(as opposed to "damage")...
] impact the end-to-end effectiveness of applications,
Damage those cause doesn't feel like something we should ask an AD
to fix!
] and how transport technologies and protocols can help to improve the
] end-to-end effectiveness of various applications.
I'm nervous about "can help" -- transport should be a generic tool,
not something we diddle to make a particular application work better.
] Intserv (RSVP) technologies reserve resources to improve quality of
] service; Diffserv is an inline mechanism to request a quality of
] service during forwarding;
Again, what do we expect NomCom to _do_ about this?
] Network-attached storage (NAS and NFS), and storage area networks
] (SAN, iSCSI, and Fibre Channel) help coordinate storage inside and
] between data centers, for virtualized environments, for large
] streaming applications, and remote replication for high availability;
I'm having trouble even parsing this... Do we believe 2013 ADs
need any expertise in NFS, etc.?
] Signaling and control protocols for peer-to-peer traffic optimization
] help to avoid congestion in the Internet, by using trackers,
] background transfers, and in-network storage.
These are legitimate TSV areas of work; but do ADs need prior
expertise in these?
] Current and new transport work includes congestion signaling and
] reporting, forward error correction, QoS and reservation signaling,
] DiffServ and congestion control for unresponsive flows,
These certainly belong in TSV; but I really doubt we need ADs with
prior expertise in each of these.
] NAT regularization and specification, storage protocols for the Internet,
] peer-to-peer streaming, performance metrics for Internet paths,
] experimentation with congestion control schemes developed in the IRTF,
I guess these belong in TSV, but IMHO they shouldn't gate on the
expertise of the TSV ADs.
] multipath extensions to existing transport protocols, congestion control
] for "background" bulk transfers, and extensions to the IETF protocols
] for multimedia transport.
I don't consider these "core" TSV work...
] The Transport Area intersects most frequently with Internet Area, the
] Applications Area, the RAI Area, the Security Area, and several IRTF
] research groups.
Of course...
] Cross-area expertise in any of those Areas would be particularly useful.
... but what do we expect the NomCom to _do_ about this?
====
Presumably this part of the "requirements" will be discussed during
IETF week; and I do hope that will be helpful. But I suggest on-list
discussion before then will be even more helpful -- especially if we
can draw in some NomCom chairs to explain which parts of this have been
hardest to satisfy.
--
John Leslie <john(_at_)jlc(_dot_)net>