Subject: [tcpm] draft-scharf-tcpm-reordering-00

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Mon, 15 Jul 2013 17:15:29 +0000

Dear all,

Given the recent discussions about head-of-line blocking in TCP, the following small ID might be of interest.

Since this stuff is hopefully well-known and obvious, I don't plan to ask for a time slot in Berlin - it would probably be a waste of scarce meeting time. But I encourage everybody to discuss the impact of head-of-line blocking here on the mailing list.

Michael (of course, with chair hat off)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, July 15, 2013 7:06 PM
To: [email-masked]
Subject: I-D Action: draft-scharf-tcpm-reordering-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Quantifying Head-of-Line Blocking in TCP and SCTP
	Author(s)       : Michael Scharf
                          Sebastian Kiesel
	Filename        : draft-scharf-tcpm-reordering-00.txt
	Pages           : 10
	Date            : 2013-07-15

Abstract:
   In order to quantify the impact of head-of-line blocking on
   application latencies, this memo provides simple analytical models
   for a "back of the envelop" estimation of the delay impact for
   reliable transport over a single TCP connection, multiple TCP
   connections, multiple SCTP streams, and unordered transport.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-scharf-tcpm-reordering

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-scharf-tcpm-reordering-00

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 15 Jul 2013 18:34:31 -0700

> Since this stuff is hopefully well-known and obvious, I don't plan to ask for a time slot in Berlin - it would probably be a waste of scarce meeting time. But I encourage everybody to discuss the i…
The issue may be well known but I am not aware of any empirical data.
There are many protocols that can address this problem:
minion, structured streams transport, SCTP, and including new QUIC
from Google. It'd be great if we can get data to justify this issue.
The metric may change for non-reliable real-time delivery such as
video conf. Deep instrumentation at the receiver queue in the stack is
a good starting point.

But overall I am glad Michael is taking the first stab.

> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Tue, 16 Jul 2013 06:46:44 +0000

> From: Yuchung Cheng [mailto:[email-masked]] 
> Sent: Tuesday, July 16, 2013 3:35 AM
> To: Scharf, Michael (Michael)
> Cc: tcpm ([email-masked])
> Subject: Re: [tcpm] draft-scharf-tcpm-reordering-00
> 
> > Given the recent discussions about head-of-line blocking in 
> TCP, the following small ID might be of interest.
> >
> > Since this stuff is hopefully well-known and obvious, I 
> don't plan to ask for a time slot in Berlin - it would 
> probably be a waste of scarce meeting time. But I encourage 
> everybody to discuss the impact of head-of-line blocking here 
> on the mailing list.
> >

As far as I know, transport protocol HOL was studied mainly for "realtime" signaling applications (e.g., SS7) in the past, typically using SCTP as transport. There are a couple of empirical studies for such signaling traffic - some older ones are referenced in our papers.

> minion, structured streams transport, SCTP, and including new 
> QUIC from Google. It'd be great if we can get data to justify 
> this issue.
> The metric may change for non-reliable real-time delivery 
> such as video conf. Deep instrumentation at the receiver 
> queue in the stack is a good starting point.

The application data arrival pattern of a real-time application such as video conferencing (without adaptive streaming) may not be too different to certain "realtime" signaling applications. This is why some of the old HOL studies may partly applicable. That is one of the key points of our small ID.

Yet, I am not aware of published work on a deep instrumentation of the receiver queue. Indeed, this would be very interesting.

Michael

> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of 
> > [email-masked]
> > Internet-Draft directories: http://www.ietf.org/shadow.html or 
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt