Subject: [BXXPwg] Re: Protocol Bindings

From: "Marshall T. Rose" <[email-masked]>
Date: Sun, 8 Jul 2001 14:18:59 -0700

[ a conversation in progress... ]

> >    head-of-line blocking goes away when you do segmentation
> >and allocations, the cost is that you sacrifice the ability to
> >operate at TCP's theoretical speeds.
>
> Regardless of segmentation, you cannot avoid outstanding data ahead of
> you having to be drained first. Additionally, in order to get reasonable
> response time from a channel, you would want fairly small segments,
> leaving applications having to cut their data into small pieces.

yes, that's the "allocations" part above, except that it's not the
application doing the cutting, it's the layer between them and tcp.

> >    deadlocks, as a potential problem, exist independently --
> >either due to poor protocol design or poor protocol implementation.
>
> An annoying aspect of communicating with somebody is that you don't
> quite have control over how they react or how many resources they have
> available :) Because channels are inherently interrelated it is always
> possible to provide scenarios where a particular segmentation/allocation
> policy gets in the way and can lead to unexpected deadlock situations
> regardless of good intentions.

i don't think this is provably true. i certainly agree that poor
implementation, either inadvertent or purposefully, on the part of one side
can lead to deadlock. but that's true of all bi-directional protocols,
including, for example, tcp.

> >    channel aborts can be handled with prioritization of a
> >control channel.
>
> Indeed but again, outstanding data will have to get drained which you
> effectively have little control over how long that might take. In
> general the purpose of channel aborts is to return the resources used as
> quickly as possible.

this isn't an argument against layers, instead, it's a truism that you can
work only with what's available. regardless of whether you are doing one
thing or many between two hosts, if the network locks up, the results are
the same.

> >none of this is rocket-science, it just requires careful
> >engineering and reasonable implementation.
>
> Certainly it can be done but it seems to me to be a slippery slope - in
> order to implement these mechanisms you will end up having to
> reimplement much of what TCP already provides and a session layer seems
> to me to be the wrong place to do that.

i suppose everything can be viewed as a slippery slope. and i'll certainly
agree that this is an area where careful implementation is necessary. which
is why, i'd rather see people implement beep as a library layer, as opposed
to just doing a quick and dirty set of subroutines in their application
programs.

> >as for the benefits:
> >    when you are able to amortize the cost of connection
> >establishment, security neogitation, and state restoration for
> >transactions involving more than one exchange, the benefits
> >become noticable.
>
> I see but tying application state to a particular transport or session
> channel doesn't seem like a good idea to me. I can't see why state
> cannot be maintained in the endpoints without having any specific link
> to the underlying transport.

efficiency argues otherwise.

the polar opposite approach is the stateless model with http, in which each
step of a transaction maps to a single transport connection, which means
that in multi-step transactions, you are constantly re-establishing state at
both the transport and application layers: tcp discards learned network
behavior, servers fork a new process (or refurbish a thread from the free
pool), peers generate session keys and authenticate certificates,
authorization databases get queried, etc., etc.

of course, if your traffic is mostly one transaction = one req/rsp = one tcp
connection, i guess it doesn't matter...

> >    when you are able to operate asynchronously in a
> >loosely-coupled system, the benefits become noticable.
>
> Absolutely - I just don't think it takes a complex session layer to get
> there. By supporting bi-directional messaging over a single TCP
> connection and then use multiple TCP connections for handling message
> interleaving, ...
>
> >because, in today's operational environments, if you originate
> >two tcp connections to the same ip address at the same time,
> >you have no guarantee that they terminate at the same system.
> >10 years ago, this wasn't an issue...
>
> This only seems to reinforce my comments about it not being a good idea
> to associate application state with the underlying transport.

i don't get your reply. what my example shows is that there is no guarantee
that multiple tcp connections will terminate at the same system. this means
that any approach trying to use multiple TCP connections for interleaving
traffic for the same session is doomed to failure.

in fact, my example reinforces just the opposite of the conclusion you
reach: if i can get establish a single tcp connection (not a sure thing in
the operational internet), then i've already survived most of the "attacks
of the middlebox". if a middlebox doesn't prevent you from reaching tcp's
established state, then it's not likely that it will mess with you any
further... (of course, that's only true of this year's boxes...)

> >regardless, when you do multiple tcp connections, then there's
> >a whole other set of problems that pop up with firewalls,
> >viz., ftp-data for the simple case...
>
> No argument there either but I can't see that this is an argument for a
> session layer. If we already have bi-directional messaging and I really
> want more than one TCP connection then why can I not ask the party that
> established the first connection to establish one more?

we really have to have a long talk about NATs some time...the operational
internet just doesn't work that way.

/mtr

_______________________________________________
BXXPwg mailing list
[email-masked]
http://lists.invisible.net/mailman/listinfo/bxxpwg

---

From: "Henrik Frystyk Nielsen" <[email-masked]>
Date: Sun, 8 Jul 2001 21:44:35 -0700

I agree with your comment on the dist-app mailing list [1] and so rather
than diving into another round I will just say thanks for your response
:)

Henrik Frystyk Nielsen
mailto:[email-masked]

[1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jul/0058.html