Re: [EME] Re: transport recovery at the APP layer ?

[Saikat Guha <[e-mail]>]

On Fri, 2006-11-17 at 10:28 -0800, Joe Touch wrote:
> 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.

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.

-- 
Saikat

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