[e2e] a new IRTF group on Transport Models

[Cannara]

Since Sally & I have exchanged a few notes on what I see as the truly serious
issue that never gets attention, I'll just mention it here once, in case some
courageous, responsible souls are out there to do for humanity what the IETF &
crew won't -- messing with TCP (or any transport) is missing the point of
congestion control.  The origin of it in TCP had nothing to do with the "e2e
principle".  It simply created a bandaid to bring the Internet back from the
edge of Metcalfe's predicted collapse that scared folks in the '80s.  

Why?  Because the Internet designers never considered anything but IP and a
few hosts (ok a few coffee pots too :).  DLC?  What's that?  Unique node
addresses?  Eh?  Admission & flow control at the network layer?  What's that? 
So, with eyes averted, ears covered and mouths that raised such issues taped
shut, we got what we have today -- a mess.  Whether or not TCP is ever given
accurate info to distinguish physical loss from true congestion matters
little.  The network layer is responsible for its own congestion management. 
That's where the Internet deserves to finally get a dose of the reality that's
been faced for decades in more reliable and secure deployed communications
systems -- real networks, in other words.

If there are such good souls ready to stand up and do what needs be done, I
applaud you.  Remember, courage men/women, God hates a coward.

Alex

Sally Floyd wrote:
> 
> Lloyd -
> 
> >But the drops of interest measured are presumably segment drops, or
> >even segments-with-piggybacked acks drops, while drops of pure acks
> >(which are logically also packet drops) are usually neglected.
> >
> >(And congestion/queue overflow/policy drops in routers are distinct
> >from discards due to detected L2/L3 checksum errors.)
> >
> >Gah, semantics.
> 
> Oh dear, and I wasn't even thinking about acks vs. data packets,
> or congestion- vs. corruption-related drops, when I wrote the earlier
> email.  (Though I am very much interested in drop rates for pure
> ack packets, as it has a big influence on the burstiness of the
> data packets subsequently transmitted in the other direction.)
> 
> I was thinking about fragmentation, where a "segment" in TCP
> might correspond to several "packets" on the wire.  Also resulting
> in a difference between packet drop rates on-the-wire and segment
> drop rates seen by the TCP sender.
> 
> Ah, semantics...
> 
> - Sally