Subject: [EME] The virtual circuit trap mentioned in the EME charter - need for clarification

From: Rémi Després <[email-masked]>
Date: Thu, 09 Nov 2006 16:45:26 +0100

The EME charter seems to me very pertinent, and I like its clarification 
of some real problems.
Although I have been involved in Internet protocols for years, and have 
been active in the 70s.on virtual circuits (by the way operational 
worldwide, and very successful, in the 80s-early 90s), I don't 
understand the sentence of the charter: which says "Candidate protocols  
should avoid falling into the virtual circuit trap, where routers  lose 
the ability to remedy failures locally".

Could anyone, clarify what is meant?

In particular,: is it understood that NATs have fallen into that trap, 
or have avoided it ?

Thanks.

Rémi Després

_______________________________________________
EME mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/eme

---

From: "Paul Francis" <[email-masked]>
Date: Tue, 14 Nov 2006 08:22:52 -0500

My interpretation of that sentence is that, in the signaling protocols we
design, we should minimize the number of machines that need to get involved
in the repair of a failure.  Mark Handley may have some additional
interpretation.

NATs are worse than VCs...there are some failures they can't recover from,
period.

PF

-----Original Message-----
From: Rémi Després [mailto:[email-masked]] 
Sent: Thursday, November 09, 2006 10:45 AM
Cc: [email-masked]
Subject: [EME] The virtual circuit trap mentioned in the EME charter - need
for clarification

The EME charter seems to me very pertinent, and I like its clarification of
some real problems.
Although I have been involved in Internet protocols for years, and have been
active in the 70s.on virtual circuits (by the way operational worldwide, and
very successful, in the 80s-early 90s), I don't understand the sentence of
the charter: which says "Candidate protocols should avoid falling into the
virtual circuit trap, where routers  lose the ability to remedy failures
locally".

In particular,: is it understood that NATs have fallen into that trap, or
have avoided it ?

Thanks.

Rémi Després

---

From: Rémi Després <[email-masked]>
Date: Tue, 14 Nov 2006 18:26:52 +0100

1. If two miidleboxes are involved in a session, is seems natural that 
the two boxes be involved if the session fails in some way.
 I don't see that the VC paradigm requires more than that.
 A sentence like"the number of machines that need to get involved in the 
repair of a failure that a  is involved should be minimized"  would be nice.
 It would convey what you mean, and it would avoid an_ unnecessary 
criticism of VCs_, based on an unknown understanding of what is a VC.

(To me, a VC is a packet exchange mechanism where the identification of 
an established VCs may change from one link to the next, a link being 
whatever is used  between two consecutive nodes that are aware of that 
VC. You may legitimately have another view, but I doubt it would be 
useful to discuss that here.)

2. I am not aware, personally, of failures of classical NATs that cannot 
be recovered (I mean those NATs that all of us use extensively)..
 But your comment raises another clarification point.
 Should the EME work provide more friendly operations of NATs, of 
IPv6/IPv4 translators, and other mioddleboxes that happen to be useful., 
or should it provide new solutions so that NATs etc. are no longer needed?
 My interpretation is that it is the first one.
 If it is so, how to exclude considering any VC related technques, only 
because VCs are considered to be bad, yet keeping NATs although they are 
considered to be even worse?

The point of all that is to help clarifying what has to be done, being 
convinced that there is something important here.

Rémi

---

From: Joe Touch <[email-masked]>
Date: Tue, 14 Nov 2006 11:10:34 -0800

> be recovered (I mean those NATs that all of us use extensively)..

When there are multiple NATs that could be used for egress or ingress.

An outgoing SYN establishes state at one NAT that is typically not
shared with the other NATs; if the routing changes behind the NAT to the
egress, or in front of the NAT on the return path, the connection
breaks. FWIW, that routing can change for many reasons, including
failure of a NAT box itself.

Whether that's recoverable depends on whether you're willing to
reestablish a connection as part of recovery.

Joe

---

From: Scott W Brim <[email-masked]>
Date: Tue, 14 Nov 2006 17:52:55 -0500

In particular, in a connection-oriented model, the intermediate
forwarders know nothing about state outside of their little world --
all they know is that if something comes in on one interface with a
particular tag, it goes out some other interface[s].  Granted it's all
they need to know, but it also means that connections are more
"brittle" (Curtis Villamizar's word).

swb

Excerpts from Paul Francis on Tue, Nov 14, 2006 08:22:52AM -0500:
> From: R?mi Despr?s [mailto:[email-masked]] 
> R?mi Despr?s

---

From: Rémi Després <[email-masked]>
Date: Wed, 15 Nov 2006 10:05:43 +0100

The connection-oriented model "per se" doesn't prohibit that 
intermediate nodes keep more information than necessary for label switching.

 As a matter of fact, in the Transpac implementation of VCs (Transpac is 
the X.25 network of France Telecom), ingress and egress nodes keep 
enough information to re-establish a VC, within the wan,  if  an 
intermediate node failure breaks it.
 The ingress node keeps a copy of enough recent user data so that, when 
the wan part of the VC is re-established, data that may have been lost 
on the fly are retransmitted. End nodes are unaware of the failure.
 Would the ingress-egress protocol used for this be also used E2E, then 
total recovery.of all  intermediate node failures would be achieved.

RD

Scott W Brim wrote

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 15 Nov 2006 08:48:44 -0500

I'm not sure it is a good omen that EME is starting off by debating X.25...
 
Why don't I just remove the mention of VCs from the charter  ;)
 
Also, I plan to submit a proposed set of requirements in the next couple
days.  That'll give us something a bit more concrete to discuss.
 
PF

________________________________

From: Rémi Després [mailto:[email-masked]] 
Sent: Wednesday, November 15, 2006 4:06 AM
To: Scott W Brim
Cc: [email-masked]
Subject: Re: [EME] The virtual circuit trap mentioned in the EME charter
-need for clarification

 The connection-oriented model "per se" doesn't prohibit that intermediate
nodes keep more information than necessary for label switching.

 As a matter of fact, in the Transpac implementation of VCs (Transpac is the
X.25 network of France Telecom), ingress and egress nodes keep enough
information to re-establish a VC, within the wan,  if  an intermediate node
failure breaks it.
 The ingress node keeps a copy of enough recent user data so that, when the
wan part of the VC is re-established, data that may have been lost on the fly
are retransmitted. End nodes are unaware of the failure.
 Would the ingress-egress protocol used for this be also used E2E, then total
recovery.of all  intermediate node failures would be achieved.

RD

Scott W Brim wrote 

	particular tag, it goes out some other interface[s].  Granted it's
all
	
	swb

		My interpretation of that sentence is that, in the signaling
protocols we
		design, we should minimize the number of machines that need
to get involved
		in the repair of a failure.  Mark Handley may have some
additional
		interpretation.
		
		NATs are worse than VCs...there are some failures they can't
recover from,
		period.
		
		PF

		-----Original Message-----
		From: Rémi Després [mailto:[email-masked]] 
		Sent: Thursday, November 09, 2006 10:45 AM
		Cc: [email-masked]
		Subject: [EME] The virtual circuit trap mentioned in the EME
charter - need
		for clarification
		
		The EME charter seems to me very pertinent, and I like its
clarification of
		some real problems.
		Although I have been involved in Internet protocols for
years, and have been
		active in the 70s.on virtual circuits (by the way operational
worldwide, and
		very successful, in the 80s-early 90s), I don't understand
the sentence of
		the charter: which says "Candidate protocols should avoid
falling into the
		virtual circuit trap, where routers  lose the ability to
remedy failures
		locally".

		In particular,: is it understood that NATs have fallen into
that trap, or
		have avoided it ?
		
		Thanks.
		
		Rémi Després

---

From: Rémi Després <[email-masked]>
Date: Wed, 15 Nov 2006 16:10:02 +0100

> Why don't I just remove the mention of VCs from the charter  ;)
That would be the best solution.
What matters is real solutions to real problems, not artificially 
opening debates about the past.

RD

---

From: Rémi Després <[email-masked]>
Date: Wed, 15 Nov 2006 16:15:17 +0100

---

From: Rémi Després <[email-masked]>
Date: Wed, 15 Nov 2006 17:18:36 +0100

Thanks for the clear case description.
 
IMHO it should be considered more a problem of "NATs that may be passed 
around with rerouting" than as a problem of "NATs" as such.
 (Most private NATs, that are the majority, cannot be passed around. No 
one would say that rerouting creates problems just because it can create 
problems when combined with NATs.)

Also, automatic reestablishment of a broken TCP connection is AFAIK 
systematic in common applications (mail, web, FTP etc.).
 It can thus be deemed that this failure case not only is "recoverable" 
but is even "recovered" in the practical world.
 (The recovery is even fast in general if the NAT which takes over, 
receiving a non-SYN TCP packet on an unknown connection, does return the 
RST which, if not lost, immediately clears the connection.)

RD

---

From: Joe Touch <[email-masked]>
Date: Wed, 15 Nov 2006 08:30:12 -0800

> problems when combined with NATs.)

Right. It's the NAT that creates the problem, because it's not tolerant
of the rerouting. Hard state in the middle of the network is dangerous
when paths are not pinned. (e.g., pinning can happen with explicit
signalling, or happens with proxies because of the termination of the
transport connection).

> RST which, if not lost, immediately clears the connection.)

It'd be useful to decide whether recovery includes the assumption that
the app layer will reconnect and restore E2E context. If that's
_assumed_ here, it'd be a first IMO.

Joe

-- 
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

---

From: Rémi Després <[email-masked]>
Date: Wed, 15 Nov 2006 17:58:18 +0100

> _assumed_ here, it'd be a first IMO.
This is IMO an important question.

We agree, I believe, that forbidding middleboxes that do some transport 
relaying is unrealistic.
(In other words, for the real world Internet,.the EME model must be 
accepted in addition to the E2E one.)

Then, there seems to be no simpler place, to recover from transport 
relay failures, than just above the transport layer..
It is thus not a surprise that  real applications, that had to adapt to 
the real transport world with no extra layer between transport and 
themselves, already have that recovery mechanism.

 It would indeed be a first _as an recognized model_, but AFAIK not in 
implemented code.

RD

---

From: Joe Touch <[email-masked]>
Date: Wed, 15 Nov 2006 09:05:01 -0800

> accepted in addition to the E2E one.)

I'm not sure we agree.

I agree that we can call a proxy a middlebox, and so long as the
endpoint KNOWS it's not talking to the ultimate end, that's fine.

I don't agree that this is OK when the endpoint doesn't know about it.
I.e., if you prefer: E2E trumps EME.

> relay failures, than just above the transport layer..

The problem with this model is that all it does is move E2E to the
application layer. The transport layer no longer becomes an E2E service,
and all the capabilities it provides - reliable transport in particular
- must be reinvented at the app layer.

That's been a step backwards, IMO.

>  It would indeed be a first _as an recognized model_, but AFAIK not in

Right. I don't agree we should recognize it where it breaks E2E. (it
doesn't break E2E when the middle is explicitly known).

JOe

---

From: "Henry Sinnreich" <[email-masked]>
Date: Wed, 15 Nov 2006 09:31:55 -0800

>The transport layer no longer becomes an E2E service, and 
>all the capabilities it provides - reliable transport in particular
>must be reinvented at the app layer.

This seems to be the case for all P2P applications running on some overlay network such as the openDHT. It certainly applies to P2P SIP.

Please see http://p2psip.org 

Transport is indeed not e2e due to NAT and as we have seen, Skype for example manages to provide e2e over discontinuities at the IP layer.

In the case of P2P SIP, the ICE protocol provides the NAT traversal at the application layer.

Thanks, Henry

-----Original Message-----
From: Joe Touch [mailto:[email-masked]] 
Sent: Wednesday, November 15, 2006 11:05 AM
To: Rémi Després
Cc: [email-masked]
Subject: [EME] Re: transport recovery at the APP layer ?

I'm not sure we agree.

JOe

---

From: Joe Touch <[email-masked]>
Date: Wed, 15 Nov 2006 09:38:47 -0800

Henry Sinnreich wrote:
> This seems to be the case for all P2P applications running on some
> overlay network such as the openDHT. It certainly applies to P2P SIP.

Agreed - that P2P reinvents networking at the application layer is
well-known.

> Transport is indeed not e2e due to NAT and as we have seen, Skype for
> example manages to provide e2e over discontinuities at the IP layer.

Transport is E2E for NAT on dial-out, and dial-in when ports are
registered at the NAT. Otherwise, right, it's not E2E, and that's where
the problems have been.

Joe

---

From: Rémi Després <[email-masked]>
Date: Thu, 16 Nov 2006 11:08:44 +0100

Joe Touch wrote:
> Rémi Després wrote:
>   
>> ... A transport layer acknowledgement (TCP ACK) doesn't mean that the
>> destination application has seen the data.
>>     
> It never did. But receiving an ACK to a FIN does.
>   
However regrettable it may be :'( , it's no true in all cases either.
 If a FIN is received by a TCP stack, it MUST be acked within 0.5 s to 
conform to RFC1122  -  4.2.3.2.
 It MAY be acked long before that. .
 If the application hasn't absorbed all buffered data before the ACK is 
sent, remaining data MAY never be received by the app.

 Since changing all TCP stacks would not be realistic, this fact of life 
has to be faced.
>> I guess what is meant by "E2E" should be clarified: transport stack 
>> to transport stack, or app to app?
>>  TCP provides only the former.
>>  What TCP does guarantee is that all received data have been sent, in
>> the same order and with no intermediate omission.
>>     
> when the connection closes, the app HAS received the data.
>   
 See above.

> ... if the TCP
> connection closes it knows that the other application has received the
> data. That's no longer true in spliced connections.
>   
It's NEVER true (see above).
Making clearer in IETF what the apps can expect from the TCP transport 
service would IMO be useful.

RD

---

From: "Paul Francis" <[email-masked]>
Date: Thu, 16 Nov 2006 09:19:55 -0500

I have long held the view that the application should assume very little from
TCP.  If the app needs an ack of some sort, then the app should provide it.
If the app really really cares about in-order bytes, it should do its own
checksums.   To do anything else is to ignore the end-to-end principle.  If
nothing else, writing apps this way saves you from having to understand the
minute details of TCP implementations!  
 
PF

From: Rémi Després [mailto:[email-masked]] 
Sent: Thursday, November 16, 2006 5:09 AM
To: Joe Touch
Cc: [email-masked]
Subject: [EME] Re: transport recovery at the APP layer ?

Joe Touch wrote: 

	Rémi Després wrote:

		... A transport layer acknowledgement (TCP ACK) doesn't mean
that the
		destination application has seen the data.

However regrettable it may be :'( , it's no true in all cases either.
 If a FIN is received by a TCP stack, it MUST be acked within 0.5 s to
conform to RFC1122  -  4.2.3.2.
 It MAY be acked long before that. .
 If the application hasn't absorbed all buffered data before the ACK is sent,
remaining data MAY never be received by the app.

 Since changing all TCP stacks would not be realistic, this fact of life has
to be faced.

		I guess what is meant by "E2E" should be clarified: transport
stack to transport stack, or app to app?
		
		 TCP provides only the former.
		 What TCP does guarantee is that all received data have been
sent, in
		the same order and with no intermediate omission.

 See above. 

	... if the TCP
	connection closes it knows that the other application has received
the
	data. That's no longer true in spliced connections.

RD

---

From: Rémi Després <[email-masked]>
Date: Thu, 16 Nov 2006 16:11:49 +0100

Not relying on sequence preservation by TCP would be IMO going too far.
Credible mechanisms are present in TCP to ensure it.
On the other hand, TCP hasn't credible mechanisms guarantee delivery to 
the destination application for data that are acknowledged by the 
destination TCP stack, even at the end of a connection.

The E2E _guarantee _that TCP provides, _application-to-application,_ is 
_data integrity_, with neither permutation nor duplication nor 
deletion,  _from the first data transmitted to the last data  
*received*_*. *
Aat the end of a connection, the destination application can know, from 
the transport layer, that it has received all transmitted data , but the 
source application cannot be sure, from the transport layer, that all 
the last data it has sent have been received.

RD

Paul Francis wrote:
> I have long held the view that the application should assume very 
> little from TCP.  If the app needs an ack of some sort, then the app 
> should provide it.  If the app really really cares about in-order 
> bytes, it should do its own checksums.   To do anything else is to 
> ignore the end-to-end principle.  If nothing else, writing apps this 
> way saves you from having to understand the minute details of TCP 
> implementations! 
>  
> PF
>
> ------------------------------------------------------------------------
> **Rémi Després wrote:
>
> Joe Touch wrote:
>> Rémi Després wrote:
>>   
>  If the application hasn't absorbed all buffered data before the ACK 
> is sent, remaining data MAY never be received by the app.
>
>  Since changing all TCP stacks would not be realistic, this fact of 
> life has to be faced.

---

From: "Paul Francis" <[email-masked]>
Date: Thu, 16 Nov 2006 11:20:48 -0500

TCP has a crappy checksum and you never know when an implementation might
have some screwy bug.  
 
If I'm transmitting some random HTML page, sure I'll rely on TCP to preserve
bytes for me.  If I'm transmitting a financial transaction, no way in hell am
I going to rely on TCP...
 
PF

From: Rémi Després [mailto:[email-masked]] 
Sent: Thursday, November 16, 2006 10:12 AM
To: Paul Francis
Cc: Joe Touch; [email-masked]
Subject: Re: [EME] Re: transport recovery at the APP layer ?

Not relying on sequence preservation by TCP would be IMO going too far.
Credible mechanisms are present in TCP to ensure it.
On the other hand, TCP hasn't credible mechanisms guarantee delivery to the
destination application for data that are acknowledged by the destination TCP
stack, even at the end of a connection. 

The E2E guarantee that TCP provides, application-to-application, is data
integrity, with neither permutation nor duplication nor deletion,  from the
first data transmitted to the last data  received. 
Aat the end of a connection, the destination application can know, from the
transport layer, that it has received all transmitted data , but the source
application cannot be sure, from the transport layer, that all the last data
it has sent have been received.

RD

Paul Francis wrote: 

	I have long held the view that the application should assume very
little from TCP.  If the app needs an ack of some sort, then the app should
provide it.  If the app really really cares about in-order bytes, it should
do its own checksums.   To do anything else is to ignore the end-to-end
principle.  If nothing else, writing apps this way saves you from having to
understand the minute details of TCP implementations!  
	 
	PF

	Rémi Després wrote:

	Joe Touch wrote: 

		Rémi Després wrote:

			... A transport layer acknowledgement (TCP ACK)
doesn't mean that the
			destination application has seen the data.

	However regrettable it may be :'( , it's no true in all cases either.
	 If a FIN is received by a TCP stack, it MUST be acked within 0.5 s
to conform to RFC1122  -  4.2.3.2.
	 It MAY be acked long before that. .
	 If the application hasn't absorbed all buffered data before the ACK
is sent, remaining data MAY never be received by the app.

			I guess what is meant by "E2E" should be clarified:
transport stack to transport stack, or app to app?
			
			 TCP provides only the former.
			 What TCP does guarantee is that all received data
have been sent, in
			the same order and with no intermediate omission.

	 See above. 

		... if the TCP
		connection closes it knows that the other application has
received the
		data. That's no longer true in spliced connections.

	It's NEVER true (see above).
	Making clearer in IETF what the apps can expect from the TCP
transport service would IMO be useful.
	
	RD

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Nov 2006 14:02:39 -0800

> sent, remaining data MAY never be received by the app.

An ACK is generated - but if there is outstanding data, it will not ACK
the seq num of the FIN.

The ACK _of the FIN_ means that all subsequent data has been received
correctly (as determined by the TCP checksum, which is not strong) by
the TCP at the other end.

As per below, there are other steps I should have noted to ensure that
the app has _read_ the data. As you and Paul observe, that may be
semantically insufficient - even if the app reads the data, if you want
to know if the app acted on it (e.g., a bank transaction), knowing that
the item was delivered or even received by the app is insufficient.

>> when the connection closes, the app HAS received the data.

When your side registers a CLOSED state, it means that the other side
has issued a CLOSE, which means the app has received all the data. It
may not have acted on it (which would require the app to ACK), but the
app has it.

> It's NEVER true (see above).

I've tried to show how this is ensured above. Please indicate where that
is incorrect. I admit I'm not absolutely sure of the mechanistic
details, but a successful close means the application has _read_ the
data you sent (which again may be insufficient).

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Nov 2006 14:02:33 -0800

I'm with Paul on the integrity stuff; Craig Partridge had a nice Sigcomm
1995 paper showing how TCP checksums could miss errors in certain cases.

However, the TCP closing tells you a few things - it does tell you that,
**as far as TCP knew**, the data was delivered inorder and reliably (to
the extent that its checksum can detect errors) to the application above
TCP, which may not be what you intended.

Joe

---

From: Yangwoo Ko <[email-masked]>
Date: Fri, 17 Nov 2006 15:43:33 +0900

Please pardon my very rude interrupt.

Are these on-topic? It is really interesting to re-consider
what successful delivery in transport layer means and how
much we can be assured by just looking at packets. But, I
think that this is useful only when this RG (implicitly or
explicitly) decides to make middleboxes do the right things
by watching these packets.

Regards

---

From: Rémi Després <[email-masked]>
Date: Fri, 17 Nov 2006 12:24:05 +0100

This discussion is IMO indeed relevant here (answer to Yangwoo).
The reason is that  part of the subject at hand is what middleboxes 
should do.
This does depend on the E2E functions of protocols on which these 
middleboxes have an action.
Among these protocols, TCP has a prominent position, in particular in 
NAT boxes..
Whether a connection close has to guarantee, or not, delivery to the 
destination application of the last data sent to it, is IMU a 
significant E2E aspect of TCP.
IMU, requirements on NATs do depend significantly on the answer.

I do agree (answer to Paul Francis) that the TCP checksum provides no 
more than what its simple design permits, and harder protections (e.g. 
that of SCTP) would be more appropriate for various applications.
One way to deal with this could be to add at the transport API some 
indication of which level of data integrity guarantee is required..

Concerning what the TCP based transport service does, comments below.

> An ACK is generated - but if there is outstanding data, it will not ACK
This is not IMU what the TCP spec says..

> may not have acted on it (which would require the app to ACK), but the
True. A host that receives a close knows that he has received all data 
sent to it before the close.
But if a host sends a close, its local transport stack receiving a 
transport layer acknowledgment for the close tells only that a transport 
stack, somewhere on the way to the application, has seen the close.
This is true even if there is no middlebox between the hosts.
Consequently, a NAT or even a TCP relay, doesn't change the nature of 
what applications may expect of the transport layer.

NOTE: In practice, for Request-Response protocols, e.g. . HTTP, a simple 
precaution at the application layer is sufficient to provide the 
desirable guarantee.
The first end to close its transmit direction (active close) must be the 
one that receives the last response of the dialog.
Before doing its active close, this "last receiver"  must be sure, at 
the application layer, that the received response is for its complete 
request..
Then the other end, the "last transmitter" receiving  a close sends a 
close for the other direction (passive close).
This way, the active closer knows that all data it has sent have been 
received (it received an application anwer for all of them).
It also knows also that it received all data sent to it since it 
received the passive close.

RD

---

From: Saikat Guha <[email-masked]>
Date: Fri, 17 Nov 2006 10:02:43 -0500

> significant E2E aspect of TCP.

TCP can only provide guarantees about TCP, and not the application above
it. Regarding connection close, consider two options:

Option #1: 
- Remote TCP closes connection after queuing packets for the app.
  Perhaps even after the app copies it into a temporary buffer.
- Result: Local app does not learn whether or not the remote app
  successfully processed the data.

Option #2:
- Remote *app* sends DONE after processing the last byte of the message.
- Local app is assured that the remote app succeeded

So my question: 
- IF you could pick the semantics, which one would you rather have?
- If #2, then does having or not having #1 matter?

-- 
Saikat

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Nov 2006 07:04:22 -0800

> by watching these packets.

The question is "to what extent do middleboxes participate in transport
protocols", and is relevant to determining the scope of the RG, as
stated in the charter.

Granted, the details of some of these discussions have proceeded down
into issues the RG should address, rather than focusing on the
high-level question of the charter. We should probably pop up to that
level at least until the charter issue is resolved.

Joe

---

From: "Mark Baker" <[email-masked]>
Date: Fri, 17 Nov 2006 11:27:14 -0500

On 11/17/06, Saikat Guha <[email-masked]> wrote:
> it.

Thank you.  I was just writing a message which was going to say exactly that.

While it's certainly true that applications are free to attribute
application layer semantics to transport layer signals (e.g. HTTP
1.0), it is not the case that all applications do so (e.g. HTTP 1.1).

Mark.

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Nov 2006 08:48:17 -0800

> 1.0), it is not the case that all applications do so (e.g. HTTP 1.1).

If you're referring to persistent connections, that predated 1.1 as an
add-on to 1.0 (though not in the base 1.0).

HTTP isn't the only application around, as you note. Unless this RG is
focused on HTTP interactions with middleboxes, it needs to consider the
impact on all applications.

Joe

---

From: "Mark Baker" <[email-masked]>
Date: Fri, 17 Nov 2006 12:40:18 -0500

> add-on to 1.0 (though not in the base 1.0).

I was referring to how HTTP 1.0 responses were framed, specifically
the last sentence of this paragraph from sec 7.2.2 of RFC 1945;

   When an Entity-Body is included with a message, the length of that
   body may be determined in one of two ways. If a Content-Length header
   field is present, its value in bytes represents the length of the
   Entity-Body. Otherwise, the body length is determined by the closing
   of the connection by the server.

... which is a layering problem that HTTP 1.1 fixed by mandating
persistent connections.

> impact on all applications.

I'm glad to hear you say that, because IMO, doing so requires keeping
our layers layered and not assuming application semantics to TCP
signals.

Cheers,

Mark.

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Nov 2006 10:28:20 -0800

> ... which is a layering problem that HTTP 1.1 fixed by mandating

See RFC2616, sec 8.1.1:

 HTTP implementations SHOULD implement persistent connections.

When they don't, the old semantics persist.

> our layers layered and not assuming application semantics to TCP

Doing that means keeping TCP semantics, which means that a FIN/ACK means
what a FIN/ACK means - that the -endpoint- got the data, not that a
middlebox somewhere else did.

Joe

---

From: "Mark Baker" <[email-masked]>
Date: Fri, 17 Nov 2006 14:44:59 -0500

>  HTTP implementations SHOULD implement persistent connections.

Right, my bad.  I meant making them the default.

> When they don't, the old semantics persist.

Old semantics persist because of compatibility rules, but I still
consider the layering problem "fixed".

Anyhow, my point is that assuming ACKed FINs meant something to the
application would break some applications that don't already make that
assumption.

> middlebox somewhere else did.

Right.  Middleboxes should behave like they're in the middle, IMO 8-)

Mark.

---

From: Saikat Guha <[email-masked]>
Date: Fri, 17 Nov 2006 15:05:34 -0500

> middlebox somewhere else did.

TCP has a number of semantics desirable and undesirable (see RFC 3135).
WGs active in IETF such as TCPM and BEHAVE are working to preserve the
semantics TCP offers. "Fixing" TCP or telling middleboxes  how to
"correctly" handle FIN packets should not be in scope of EME.

As I understand it (see attached illustration), EME is considered with
the interface between the application and the Internet layers. e.g. 
- How to identify the remote app instance? How to find it?
- How to forge a path through the network to that instance? 
- What protocol modules to use (e.g. TCP, SCTP etc.) 
- How to take into account middleboxes (e.g. NATs, firewalls) should
  topology or policy require them?
- How to take into account network policy (e.g. corporate HTTP proxy)? 
- How to discover these middleboxes that need to be contacted?
- How to reestablish the app-to-app path if something fails?
- How to close flows with determinate application-level guarantees?
- ... and so on (the blue parts in the attached illustration)

Should the path forged include a TCP link or a NAT/firewall, the TCPM
and BEHAVE WGs define the protocol, semantics, who sends what packet and
what that means for that protocol etc. IMHO, that should be out of scope
of EME.

---

From: Joe Touch <[email-masked]>
Date: Fri, 17 Nov 2006 12:14:03 -0800

> "correctly" handle FIN packets should not be in scope of EME.
...
> what that means for that protocol etc. IMHO, that should be out of scope

EME is a RG. IMO, it should definitely explore this interaction and
advise the IETF, which would then help set boundaries for future
TCPM/BEHAVE/etc. WGs. Those issues should not be driven by WGs.

Joe

---

From: Rémi Després <[email-masked]>
Date: Sat, 18 Nov 2006 11:23:05 +0100

Joe Touch wrote
> TCPM/BEHAVE/etc. WGs. Those issues should not be driven by WGs.
I agree with Joe that IETF ongoing work should NOT restrict the scope of 
an IRTF research group.
Experiments, in particular with running code, may be precious input to IETF.
TCPM/BEHAVE scopes should therefore not restrict that of EME..

As the reciprocal is also appropriate, works of EME and  TCPM/BEHAVE can 
progress in parallel, with mutual influence whenever  it happens to be 
useful.

RD

---

From: Rémi Després <[email-masked]>
Date: Sat, 18 Nov 2006 12:15:03 +0100

> middlebox somewhere else did.
Sorry to insist that AFAIK this statement is inaccurate, at least if, as 
I understand it, the endpoint refers to the application that uses TCP.

YES, when an application receives a FIN, it _does mean_ that it has 
received all its incoming data have been received.
But NO, after an application has sent a FIN, reception of the ACK for 
that FIN by its TCP stack _doesn't mean_ that all its outgoing data have 
been received  by the far end application.
AFAIK _the application that sends a FIN is not even informed that the 
FIN has been acknowledged _ (no provision for this at its socket API 
with its TCP stack). .

It would be nice if some recognized TCP stack specialist would  help 
reaching a common understanding on this point.

RD

---

From: Joe Touch <[email-masked]>
Date: Sat, 18 Nov 2006 10:25:18 -0800

> been received  by the far end application.

It does mean that the TCP stack has received all outstanding data that
preceded the FIN.

> FIN has been acknowledged _ (no provision for this at its socket API

There are no async signals to the app; it's always the app's
responsibility to check the state. The app must issue a READ on the
connection after issuing a CLOSE until the response is that there is no
data and the request returns a status "CLOSED".

Joe

---

From: Rémi Després <[email-masked]>
Date: Mon, 20 Nov 2006 15:32:16 +0100

> data and the request returns a status "CLOSED".
Both of us agree that, if application A closes a connection it has with 
application B, _and knows that B never closes itself before it has been 
returned a CLOSED status_, then A can take the return of a CLOSED status 
as a guarantee that all data sent to B have been received.

Its OK with me if we leave the discussion at this point (our difference 
of view is on something else, probably not worth clarifying here).

RD

---

From: Lars Eggert <[email-masked]>
Date: Tue, 21 Nov 2006 11:13:25 +0200

On Nov 18, 2006, at 12:23, Rémi Després wrote:
> I agree with Joe that IETF ongoing work should NOT restrict the  
> scope of an IRTF research group.

I don't read Joe's statement (which I agree with) to mean what you  
paraphrased it as.

But in any case, IETF WG charters cannot place restrictions on what  
EME can or cannot look at. The only potential for conflicts I can see  
is if work in EME is based on certain assumptions that are later  
invalidated by new IETF standards. It be good if such cases could be  
identified early on.

Lars