Subject: [tsv-area] TSVAREA presentation slots for Stockholm

From: Eggert Lars (Nokia-NRC/Espoo) <[email-masked]>
Date: Wed, 3 Jun 2009 18:59:27 +0200

Hi,

please send agenda requests for TSVAREA in Stockholm to [email-masked] 
, including:

	title/topic
	presenter
	requested time

The purpose of the TSVAREA meeting is to inform about and discuss  
important issues, developments and work within the transport area or  
outside work that impacts the transport area. In contrast to TSVWG,  
TSVAREA does not produce any documents. TSVAREA can include tutorial- 
style talks on transport topics, maybe based on related IRTF or other  
research work. Another possibility is "mini-BOFs", where interested  
people can get quick feedback on BOF ideas they may have.

Lars

---

From: <[email-masked]>
Date: Wed, 3 Jun 2009 21:25:07 +0100

Lars,

there's work going on in various places in splitting http from tcp
to run over other transports - drafts on e.g. http over sctp,
basically taking advantage of the forward thinking in the
http/1.1 spec. It's basically creating http as a separate layer,
decoupled from TCP.

(We also have work leveraging this decoupling to create an http
useful for DTN networks.)

Of interest? This work is happening in various places and across
various groups, but right now doesn't seem to be that coordinated.
May be worth considering in the transport area?

Title: Turning HTTP into a full-fledged networking layer
Presenter: Lloyd Wood
Requested time: 10 mins.

thanks,

L.

<http://www.ee.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

-----Original Message-----
From: [email-masked] on behalf of Eggert Lars (Nokia-NRC/Espoo)
Sent: Wed 2009-06-03 17:59
To: TSV Area
Cc: [email-masked]; TSV Dir
Subject: [tsv-area] TSVAREA presentation slots for Stockholm
 
Hi,

	title/topic
	presenter
	requested time

Lars

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 4 Jun 2009 17:40:26 +0200

> Title: Turning HTTP into a full-fledged networking layer

I think this belongs in app area and needs a better title.

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 4 Jun 2009 16:56:40 +0100

Not sure it's an application issue, as there is work to be done on the  
transports.
See e.g.
http://tools.ietf.org/html/draft-natarajan-http-over-sctp
http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery

As for a better title:
"Turning HTTP into a standalone layer in the stack"?

> I think this belongs in app area and needs a better title.

DTN work: http://info.ee.surrey.ac.uk/Personal/L.Wood/saratoga/

<http://info.surrey.ac.uk/Personal/L.Wood/><[email-masked]>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 4 Jun 2009 18:03:46 +0200

On 4 jun 2009, at 17:56, Lloyd Wood wrote:

> Not sure it's an application issue, as there is work to be done on  
> the transports.

No, the transports are already there, it's adapting HTTP to using them.

> "Turning HTTP into a standalone layer in the stack"?

Yes, much better. You _may_ be suggesting that HTTP perform transport  
layer functions (although I don't think so) but certainly not network  
layer functions.

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Jun 2009 09:21:44 -0700

> No, the transports are already there, it's adapting HTTP to using them.

That sounds right to me. Why wouldn't this be in the HTTP WG?

FWIW - the HTTP over SCTP paper has issues, notably the claims about
SCTP avoiding TIME-WAIT. If anyone bumps into them or knows where that
discussion is happening, it might be useful to point them to the recent
thread on that issue on this list.

Joe

---

From: "Eddy, Wesley M. (GRC-MS00)[Verizon]" <[email-masked]>
Date: Thu, 4 Jun 2009 11:24:58 -0500

I tend to agree with Lloyd on this question.  The distinction
between these two layers (transport and application) is quite
blurry when it comes to "applications" that end up being used
as middleware for other applications.  Application protocols
stacked on other application protocols 3 or 4 deep is no longer
uncommon, and definitely makes our layering models look
ridiculous.  Personally, the model we have where layers have
particular names ("link", "network", "transport", etc.) has
been useful to get this far, but needs to be thrown away to
progress.  Does anyone really enjoy explaining to their interns
and students that IPsec is layer 3 1/3 and MPLS is layer 2.5
after they've only just begun to grok the basic layered model?

To me, if a piece of code is controlling transmission in terms of
things like timing, segmentation/reassembly, error checking, ACK,
retransmission, on behalf of some set of applications, then it
smells a lot like a "transport".  John Day has noticed that the
same thing can be said about part of the link layer, and realized
that these are all just different flavors of the same flow and
error-control parent class in his PNA.  This fits reality much
better than giving strict names to layers at what have now become
arbitrary points within the stack.

But back to the point on this thread ... considering that the
proposal is to use HTTP to provide an interface for transport
services, and not to extend HTTP as it also exists as a
top-of-the-stack application, it is definitely more applicable
to the TSV area than the APP area.

---------------------------
Wes Eddy
Network & Systems Architect
Verizon FNS / NASA GRC
Office: (216) 433-6682
---------------------------

>From: [email-masked] [mailto:[email-masked]] On
>Behalf Of Lloyd Wood
>Sent: Thursday, June 04, 2009 11:57 AM
>To: Iljitsch van Beijnum
>Cc: TSV Area
>Subject: Re: [tsv-area] TSVAREA presentation slots for Stockholm
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Jun 2009 09:40:50 -0700

Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:
...
> smells a lot like a "transport".

Muxing in HTTP ended up reinventing a lot of transport solutions exactly
because HTTP tried too hard to run many exchanges over a single
connection. That doesn't make it a transport protocol, though - it may
just have issues similar to the transport layer.

> John Day has noticed that the
> error-control parent class in his PNA.

FYI, our Recursive Network Architecture had come to the same conclusion
and has been implemented:

Touch, J., and Pingali, V. K.,  "The RNA Metaprotocol" in Proc. IEEE
ICCCN (Future Internet Architectures and Protocols track), St. Thomas,
Virgin Islands, August 2008.

Touch, J., Wang. Y., and Pingali, V., "A Recursive Network
Architecture," ISI Technical Report ISI-TR-2006-626, October 2006.

Joe

---

From: Scott Brim <[email-masked]>
Date: Thu, 04 Jun 2009 12:49:32 -0400

In cases like these, one should avoid trying to wedge protocols into
1970s concepts.  It looks like the point of the work is to use HTTP as a
general purpose switching header.  This is what you get with Ethernet,
IP ... and mail and Web Services (leaving out connection-oriented
protocols).  Just because you switch on it doesn't decide what "layer"
it is in the old OSI model.  If

  - it has its own namespace
  - you switch on it
  - it has its own fault detection

then you might be better off calling it a "layer network" (q.v.) e.g.
http://www.niven-jenkins.co.uk/An%20introduction%20to%20functional%20architecture.pdf

In any case just because something is used to perform functions similar
to those in the transport or internet layers doesn't mean it belongs in
the Transport or Internet _Areas_.  That is more determined by the
protocols being worked on.  If it's work on HTTP, imho that belongs in Apps.

Scott

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 4 Jun 2009 18:47:00 +0100

On 4 Jun 2009, at 17:21, Joe Touch wrote:
>>> the

If you mean httpbis, its charter has been deliberately very limited to
rule out, well, everything pretty much other than revising rfc2616.

> thread on that issue on this list.

You could send the authors mail...

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 5 Jun 2009 13:12:38 +0200

On 4 jun 2009, at 18:24, Eddy, Wesley M. (GRC-MS00)[Verizon] wrote:

> The distinction
> uncommon,

Why is this a good idea, though? If a packet gets lost doesn't TCP  
retransmit? If data doesn't fit in one packet, doesn't TCP segment? If  
you prick it, doesn't TCP bleed?

I.e., what is the benefit of the extra protocols in the middle?

> to the TSV area than the APP area.

Can you explain a bit more? HTTP runs over a "real" transport  
protocol. I assume this won't change. Do the internals of HTTP change?  
Or its interface to upper layers?

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 5 Jun 2009 13:04:30 +0100

On 5 Jun 2009, at 12:12, Iljitsch van Beijnum wrote:

> retransmit? If data doesn't fit in one packet, doesn't TCP segment?  
> If you prick it, doesn't TCP bleed?
>

Abstraction. If you write an application that uses network  
communications, why would you write low-level socket code in this day  
and age? You'd write to a higher level of abstraction and avoid  
reinventing the wheel.

And this higher level of abstraction can run over protocols that are  
not TCP.
You want SOAP over SCTP? Well, HTTP over SCTP is needed. Running XML- 
RPC in a low-latency cluster where TCP is a bottleneck? Replace TCP  
with something higher-performing, without changing or rewriting the  
rest of the stack above HTTP.

(*cough* session layer *cough*)

> protocol. I assume this won't change. Do the internals of HTTP  
> change? Or its interface to upper layers?

Do the internals of TCP change when it's running over IPv4 vs IPv6?
Does the interface to upper layers change?

There's a question as to how much HTTP gets adapted for each local  
transport protocol,
or whether HTTP just uses the 'reliable bytestream' paradigm as the  
bare minimum.

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Jun 2009 07:54:14 -0700

Lloyd Wood wrote:
...
> Does the interface to upper layers change?

Actually, yes - the pseudoheader over which the checksum is computed
channges. So too does ICMP signalling, setting of the DF bit for
fragmentation discovery (clearing it doesn't have the same effect in v6
as in v4), etc.

;-)

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 5 Jun 2009 17:05:13 +0100

> fragmentation discovery (clearing it doesn't have the same effect in  

...so, by analogy, there's likely a need to describe HTTP over different
transports, what is different, and what changes.

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Jun 2009 09:28:42 -0700

> transports, what is different, and what changes.

Yes - I thought that's where they were going with the SCTP stuff.

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 5 Jun 2009 18:19:01 +0100

> Yes - I thought that's where they were going with the SCTP stuff.

Right. But are there more general 'HTTP over transport X' rules or
conventions that need to be described?

L.

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Jun 2009 10:23:17 -0700

> conventions that need to be described?

I'd hope that a general decoupling would be useful, then a set of
mappings, one for each transport. That sort of regularity hasn't been
common - either in the IETF as a whole or in the past evolution of HTTP,
though ;-)

Are we trying to encourage them to do that, or just overseeing how it
evolves?

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 5 Jun 2009 18:40:14 +0100

> Are we trying to encourage them to do that, or just overseeing how it

Neither. We're interested in using the result, even if we have
to describe it ourselves.

http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery
http://tools.ietf.org/html/draft-wood-tae-specifying-uri-transports
http://personal.ee.surrey.ac.uk/Personal/L.Wood/publications/internet-drafts/draft-wood-dtnrg-http-dtn-delivery/lloyd-wood-http-dtn-delivery-ietf-71-dtnrg-session.pdf

---

From: Joe Touch <[email-masked]>
Date: Fri, 05 Jun 2009 10:48:58 -0700

Lloyd Wood wrote:
...
> to describe it ourselves.

Understood about who does it; the question remains as to whether we care
how orthogonal the result is or whether we are focused on making sure
the result just makes the right assumptions about TCP or SCTP. I would
presume - as a group - the latter is the concern...

Joe

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Sun, 7 Jun 2009 11:32:32 +0200

> communications, why would you write low-level socket code in this  
> day and age? You'd write to a higher level of abstraction and avoid  
> reinventing the wheel.

Reusing code always seems like a good idea until you actually try to  
make it work.

Regardless, a piece of reusable code doesn't automatically make for a  
protocol.

> (*cough* session layer *cough*)

Sessions with HTTP? Ha.

> Does the interface to upper layers change?

Is answering a question with a question useful?

After a dozen or so messages it's still profoundly unclear to me what  
the work would be that we're talking about. But everything that's  
mentioned is something relevant to applications, not the internals of  
transport protocols.

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 8 Jun 2009 08:46:10 +0100

On 7 Jun 2009, at 10:32, Iljitsch van Beijnum wrote:

> Regardless, a piece of reusable code doesn't automatically make for  
> a protocol.

When that piece of reusable code communicates over the network in  
standardised ways, it does.

(Other benefits in this particular case are outlined in draft-wood- 
dtnrg-http-dtn-delivery.)

>> (*cough* session layer *cough*)

HTTP/1.1's persistence, pipelining and chunked transfer encoding give  
it a level of control that can be argued to be session management.  
It's a lot more than 'open TCP connection/send one thing/close TCP  
connection' these days.

> Is answering a question with a question useful?

It deliberately set up discussion of an analogy in later emails in the  
thread, which you may not have read.

> After a dozen or so messages it's still profoundly unclear to me  
> what the work would be that we're talking about. But everything  
> that's mentioned is something relevant to applications, not the  
> internals of transport protocols.

I look forward to going to the apps area to be told that defining HTTP- 
over-Transport-X is a transport problem.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 8 Jun 2009 13:15:15 +0200

On 8 jun 2009, at 9:46, Lloyd Wood wrote:

> Other benefits in this particular case are outlined in draft-wood- 

http://tools.ietf.org/html/draft-wood-dtnrg-http-dtn-delivery-03

I haven't followed delay tolerant networking, but using HTTP here  
seems rather curious to me unless the delay toleration isn't very  
ambitious, as HTTP is a request/response protocol. This means that if  
you want to use it towards the Cassini orbiting Saturn, you're wasting  
half an RTT (about 1.3 hours) of usable communication time waiting for  
the HTTP request to get there. If each side can autonomously send  
messages without a request/response cycle that's much more efficient.

Also, the MD5 business is extremely curious, this is just an  
invitation to implementers to play fast and loose with the underlying  
reliable transport that HTTP requires.

> HTTP/1.1's persistence, pipelining and chunked transfer encoding  
> give it a level of control that can be argued to be session  
> management.

In the OSI reference model, the session layer is above the transport  
layer, which means that you can maintain a session across transport  
instances. This is a very weak point in HTTP (which pipelining etc  
don't address), although of course many people have implemented hacks  
to do exactly this.

> I look forward to going to the apps area to be told that defining  
> HTTP-over-Transport-X is a transport problem.

Well, IP over ethernet is an internet standard, not an IEEE standard.  
I would be surprised if the app people sent you back here.

---

From: Lloyd Wood <[email-masked]>
Date: Mon, 8 Jun 2009 13:40:39 +0100

On 8 Jun 2009, at 12:15, Iljitsch van Beijnum wrote:

> ambitious, as HTTP is a request/response protocol.

use of PUT gets around the initial request and response for long-delay  
links.

('Delay-tolerant' is really an umbrella term to mean 'delay and  
disruption tolerant' these days, widening the scope from the original  
deep-space scenarios you discuss to include everything that is not the  
terrestrial internet. The term itself has become something of a  
misnomer for the majority of scenarios, but it's still on the banner  
being waved by academic research.)

> This means that if you want to use it towards the Cassini orbiting  
> Saturn, you're wasting half an RTT (about 1.3 hours) of usable  
> communication time waiting for the HTTP request to get there. If  
> each side can autonomously send messages without a request/response  
> cycle that's much more efficient.

again, PUT allows that. The responses (if any - I can see a case for  
blind unidirectional PUTs) get daisy-chained into the persistent  
pipeline going the other way. The long propagation delay due to the  
speed of light is unavoidable, but handshaking in initial request/ 
response setup can be prevented, leading to a one-RTT exchange time.

> invitation to implementers to play fast and loose with the  
> underlying reliable transport that HTTP requires.

Having a high-level e2e check is useful. I don't see how checking data  
reliability is an invitation to play fast and loose with the transport  
underneath. When dealing with disrupted networks, links that change  
quality or drop unexpectedly, etc., Content-Length: and Content-MD5:  
become useful in evaluating whether what has been received is  
worthwhile or should be discarded. Content-MD5: becomes particularly  
useful for checking reassembly of partial transfers. And, of course,  
in this dtn approach the data is copied multiple times across multiple  
transfers across multiple separate concatenated reliable transports.  
Always useful to be able to verify that what comes out of the end of  
that process is what went in before giving it to the app.

> instances.

If the application is entirely unaware of whether the http library  
opens a new tcp stream, or reuses an existing one, I'd argue that it  
thinks that a session is being maintained...

Using the same OSI model argument, the transport layer is above the  
network layer, which means that you can maintain a transport across  
network instances. Ergo, TCP, which traditionally sucks at multihoming  
and having addresses change on it, is not a(n OSI) transport layer[*].  
But we knew that. The 'session' label still fits, even if the OSI  
dogma does not.

[*] While SCTP is, which somehow figures since it was designed to  
support ITU-T SS7 telephone networks...

> This is a very weak point in HTTP (which pipelining etc don't  
> address), although of course many people have implemented hacks to  
> do exactly this.

---

From: Joe Touch <[email-masked]>
Date: Mon, 08 Jun 2009 06:55:34 -0700

Lloyd Wood wrote:
...
...
> pipeline going the other way.

It's easy to implement PUT without a response.

	http-over-dtb PUT-request.txt >> /dev/null

A return response code (succeed/fail) is required, or this isn't HTTP
anymore.

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 9 Jun 2009 11:33:38 +0100

Having a sender using a unidirectional transmit-only link add a
Connection: cannot-hear-response
or similar header to its PUT request as a warning to the receiver
seems straightforward.

Of limited utility, in very rare unusual situations.

---

From: Joe Touch <[email-masked]>
Date: Tue, 09 Jun 2009 06:33:21 -0700

> Of limited utility, in very rare unusual situations.

Agreed. My only point was that such an HTTP directive does not yet
exist. HTTP is currently a two-party protocol, and cannot work
unidirectionally until altered to do so.

Joe

---

From: Lars Eggert <[email-masked]>
Date: Mon, 15 Jun 2009 12:41:40 +0300

Hi,

> to the TSV area than the APP area.

I tend to agree with Wes here. Lloyd, would you take this to the APP  
area?

Thanks,
Lars

---

From: Eggert Lars (Nokia-NRC/Espoo) <[email-masked]>
Date: Mon, 15 Jun 2009 12:43:14 +0300

Hi,

please send agenda requests for TSVAREA in SF to tsv- 
[email-masked], including:

	title/topic
	presenter
	requested time

So far, our agenda is pretty short:

	Rethinking Transport Services
	Janardhan Iyengar
	30 minutes

Lars

---

From: <[email-masked]>
Date: Mon, 15 Jun 2009 16:51:09 +0100

Lars,

Sorry, I'm confused. In your email below you agree with Wes that
the work is more applicable to TSV than to APP, yet you want
me to take it to APP? Because it's more applicable to TSV?

puzzled,

L.

-----Original Message-----
From: Lars Eggert [mailto:[email-masked]]
Sent: Mon 2009-06-15 10:41
To: Eddy, Wesley M. (GRC-MS00)[Verizon]
Cc: Wood L Dr (Electronic Eng); Iljitsch van Beijnum; TSV Area
Subject: Re: [tsv-area] TSVAREA presentation slots for Stockholm
 
Hi,

Thanks,
Lars

---

From: Lars Eggert <[email-masked]>
Date: Tue, 16 Jun 2009 12:33:37 +0300

Hi,

> me to take it to APP? Because it's more applicable to TSV?

you're rightfully confused - I didn't read Wes email correctly.

After all the feedback you've gotten, do you still want time in TSV?  
Or do you prefer to take it to APP?

Lars

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 16 Jun 2009 11:13:45 +0100

Lars,

my take (agreeing with Wes) is that this work is very relevant to,  
applicable to, and impinges on TSV.

If you have the time available and nothing else pressing to fill it,  
we can happily fill a slot.

thanks,

L.

---

From: Eggert Lars (Nokia-NRC/Espoo) <[email-masked]>
Date: Wed, 17 Jun 2009 11:58:40 +0300

Hi,

here's a first cut at our SF agenda. We have time left.

TSVAREA preliminary agenda (dated 2009-06-17)
IETF-75, Stockholm, Sweden

Chairs:   Magnus Westerlund <[email-masked]>
           Lars Eggert <[email-masked]>

	Agenda Bashing
	Note Well
	State of the Area
	15 minutes
	
	Quo Vadis, DCCP?
	Pasi Sarolahti
	15 minutes

	Turning HTTP into a full-fledged networking layer
	Lloyd Wood
	15 mins
	
	[unallocated]

Please send agenda requests to [email-masked], including:

	title/topic
	presenter
	requested time

Lars