I definitely agree on the importance of Joe's first bullet:

>>      - segmentation, MTU, and message boundary issues

MTU issues come up on a regular basis, especially discovery and what to do
about a discovered MTU that's smaller than ideal, and at least MTU discovery
is currently viewed as a Transport Area responsibility.  At least one of the
two Transport ADs should have a solid command of MTU discovery, as that's
needed every so often to keep others honest.

Also, I noticed this buried in the description of managing Transport Area
work:

   QoS and reservation signaling, DiffServ? and congestion control for
   unresponsive flows,

DiffServ is definitely still relevant, as there's current DiffServ-related work.
Suggested rephrasing:

   QoS (including Differentiated Services and reservation signaling), and
   congestion control for unresponsive flows.

Thanks,
--David

> -----Original Message-----
> From: tsv-area [mailto:[email protected]] On Behalf Of Joe Touch
> Sent: Friday, May 29, 2015 4:42 PM
> To: John Leslie
> Cc: [email protected]
> Subject: Re: FYI draft text desired expertise TSV AD (NOMCOM 2015 cycle)
> 
> IMO, these are as critical to many transport discussions as knowledge of
> congestion control.
> 
> Joe
> 
> 
> On 5/29/2015 1:38 PM, John Leslie wrote:
> > Joe Touch <[email protected]> wrote:
> >>
> >> I don't disagree with anything in the text, but it seems to omit a few
> >> key areas that I think are also aspects of transports besides
> >> flow/congestion control-ish. These might also be listed among the
> >> topics/examples:
> >>
> >>    - segmentation, MTU, and message boundary issues
> >>    - connection state management
> >>    - deep-packet inspection interactions
> >>    - interactions with timing and latency
> >>    - end-to-end error detection and correction
> >
> >    All of these are "nice to have" -- understanding of MTU is especially
> > nice-to-have.
> >
> >    But none of them are critical to a TSV AD doing his/her job.
> >
> >    IMHO, of course.
> >
> >    YMMV...
> >
> > --
> > John Leslie <[email protected]>
> >

Reply via email to