Subject: [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols?

From: Bob Briscoe <[email-masked]>
Date: Mon, 4 Nov 2013 22:03:45 +0000

Folks,

Pls respond if you support this being adopted as a work-group item in 
the IETF transport services w-g (tsvwg). The WG chairs need 
visibility of interest.
Even better, if you're willing to read / comment / review / implement

Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP
<http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines>

Abstract

    The purpose of this document is to guide the design of congestion
    notification in any lower layer or tunnelling protocol that
    encapsulates IP.  The aim is for explicit congestion signals to
    propagate consistently from lower layer protocols into IP.  Then the
    IP internetwork layer can act as a portability layer to carry
    congestion notification from non-IP-aware congested nodes up to the
    transport layer (L4).  Following these guidelines should assure
    interworking between new lower layer congestion notification
    mechanisms, whether specified by the IETF or other standards bodies.

[Cross-posting tsvwg & aqm, just in case]

Bob Briscoe,
also for co-authors Pat Thaler and John Kaippallimalil

________________________________________________________________
Bob Briscoe,                                                  BT

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Mon, 4 Nov 2013 22:39:09 +0000

On Nov 4, 2013, at 2:03 PM, Bob Briscoe <[email-masked]> wrote:

> Folks,
> 
> Pls respond if you support this being adopted as a work-group item in the IETF transport services w-g (tsvwg). The WG chairs need visibility of interest.

And don't respond if we don't support it? :-)

I have a very basic question. For IP/IP tunnels, such as GRE, the ECN flags are defined, and I would imagine that RFC 2983 could be interpreted as saying what one does with flags (when you move the TOS octet, move 8 bits, whether in->out or out->in). For non-IP tunnels, with the exception of MPLS, the IETF doesn't define the header.

How does one add ECN to a protocol we don't maintain? If we maintain it, are we already done?

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

------------------------------------------------------
8 issues in virtual infrastructure
http://dcrocker.net/#fallacies

---

From: Bob Briscoe <[email-masked]>
Date: Mon, 4 Nov 2013 22:44:48 +0000

Fred,

At 22:39 04/11/2013, Fred Baker (fred) wrote:

> > Pls respond if you support this being adopted as a work-group 
> item in the IETF transport services w-g (tsvwg). The WG chairs need 
> visibility of interest.
>
>I have a very basic question. For IP/IP tunnels, such as GRE, the 
>ECN flags are defined, and I would imagine that RFC 2983 could be 
>interpreted as saying what one does with flags (when you move the 
>TOS octet, move 8 bits, whether in->out or out->in). For non-IP 
>tunnels, with the exception of MPLS, the IETF doesn't define the header.
>

The idea is to issue liaison statements to make the relevant stds 
bodies aware of this. E.g.:
- to 3GPP for GTP,
- to IEEE for 802.

The IETF maintains a number of the relevant tunnelling protocols it 
mentions, e.g.
L2TP, GRE, PPTP.

---

From: Andrew Mcgregor <[email-masked]>
Date: Tue, 5 Nov 2013 10:04:01 +1100

This seems like valuable work.  One question is, can we put in scope
notification that losses are NOT due to congestion?

Willing to comment and review, at least.

On 5 November 2013 09:03, Bob Briscoe <[email-masked]> wrote:

> Folks,
>
> Pls respond if you support this being adopted as a work-group item in the
> IETF transport services w-g (tsvwg). The WG chairs need visibility of
> interest.

-- 
Andrew McGregor | SRE | [email-masked] | +61 4 8143 7128

---

From: Matt Mathis <[email-masked]>
Date: Mon, 4 Nov 2013 15:16:30 -0800

I think this is valuable work.  Having a single document that describes the
requirements and general principles will save future tunnel
inventor/implementers from rediscovering the same bugs

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay

Privacy matters!  We know from recent events that people are using our
services to speak in defiance of unjust governments.   We treat privacy and
security as matters of life and death, because for some users, they are.

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 5 Nov 2013 00:00:26 +0000

Andrew,

Thx for supporting words and offer of help.

>notification that losses are NOT due to congestion?

Eyooow. That really does not belong in this scope.

This is about the interface between lower layers and the ECN field in 
the IP header. We can't really talk about new semantics in lower 
layers that aren't even defined in ECN at the IP layer.

Naively, one could imagine some text treating the ECN field as 4 
opaque codepoints, and propagating  a similar 4 opaque codepoints 
from each lower layer protocol. Then if something new were defined in 
IP-ECN like a non-congestive loss codepoint, it could also be defined 
in lower layers...

But that's naive, because each lower layer has it's own constraints 
and ways of handling concepts like "ECN-capable transport", none of 
which easily translates to a simple mapping of codepoints.

Explicit signalling of non-congestive loss is a research problem, because...
* Clearly a link cannot signal that a loss was not due to congestion 
using the lost frame itself (there aren't any bits :)
* So the link would have to signal in another frame that didn't get corrupted.
   - That frame may go to another process that didn't see any loss; 
then what does the process do?
   - or the link has to use DPI to signal only in frames going to the 
same process as the lost frame.
   - that means the link has to understand all transport protocols

There's other hard problems
* A transmission loss doesn't always mean there is no congestion loss
* At my last count, there were at least nine different reasons for 
packet loss. If we had 4 bits spare in each lost packet... :)

Bob

>On 5 November 2013 09:03, Bob Briscoe 
><<mailto:[email-masked]>[email-masked]> wrote:
>Folks,
>
>Pls respond if you support this being adopted as a work-group item 
>in the IETF transport services w-g (tsvwg). The WG chairs need 
>visibility of interest.
><<http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines>http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines>
>
>Abstract
>
><mailto:[email-masked]>[email-masked]
>Andrew McGregor | SRE | 
><mailto:[email-masked]>[email-masked] | +61 4 8143 7128

---

From: Michael Welzl <[email-masked]>
Date: Mon, 4 Nov 2013 16:02:32 -0800

+1

On 4. nov. 2013, at 15:16, Matt Mathis <[email-masked]> wrote:

> I think this is valuable work.  Having a single document that describes the requirements and general principles will save future tunnel inventor/implementers from rediscovering the same bugs
> 
> Thanks,
> --MM--
> Privacy matters!  We know from recent events that people are using our services to speak in defiance of unjust governments.   We treat privacy and security as matters of life and death, because for some users, they are.
> 
>

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Tue, 5 Nov 2013 00:48:43 +0000

(aqm chair hat off)

I can fully support what Matt just stated!

I have read an earlier version (-01 iirc), I'll try to scan over this version in the coming days.

Richard Scheffenegger

From: [email-masked] [mailto:[email-masked]] On Behalf Of Matt Mathis
Sent: Montag, 04. November 2013 15:17
To: Bob Briscoe
Cc: [email-masked]; tsvwg IETF list; AQM IETF list
Subject: Re: [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols?

Thanks,
--MM--

On Mon, Nov 4, 2013 at 2:03 PM, Bob Briscoe <[email-masked]<mailto:[email-masked]>> wrote:
Folks,

Abstract

Bob Briscoe,

________________________________________________________________
Bob Briscoe,                                                  BT
_______________________________________________
aqm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/aqm

---

From: "Rong Pan (ropan)" <[email-masked]>
Date: Tue, 5 Nov 2013 01:13:57 +0000

I agree. This would be valuable work…

Rong

From: <Scheffenegger>, Richard <[email-masked]<mailto:[email-masked]>>
Date: Monday, November 4, 2013 5:48 PM
To: Matt Mathis <[email-masked]<mailto:[email-masked]>>, Bob Briscoe <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, tsvwg IETF list <[email-masked]<mailto:[email-masked]>>, AQM IETF list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols?

(aqm chair hat off)

I have read an earlier version (-01 iirc), I’ll try to scan over this version in the coming days.

Richard Scheffenegger

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Matt Mathis
Sent: Montag, 04. November 2013 15:17
To: Bob Briscoe
Cc: [email-masked]<mailto:[email-masked]>; tsvwg IETF list; AQM IETF list
Subject: Re: [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols?

Thanks,
--MM--

Abstract

Bob Briscoe,

---

From: Michael Menth <[email-masked]>
Date: Tue, 05 Nov 2013 08:36:21 +0100

+1

We need such guidelines for consistent congestion management.

Best wishes,

Michael

Am 05.11.2013 00:16, schrieb Matt Mathis:
> I think this is valuable work.  Having a single document that
> describes the requirements and general principles will save future
> tunnel inventor/implementers from rediscovering the same bugs
>
> Thanks,
> --MM--
> services to speak in defiance of unjust governments.   We treat
> privacy and security as matters of life and death, because for some
> users, they are.
>
>
>     [email-masked] <mailto:[email-masked]>

-- 
Prof. Dr. habil. Michael Menth
University of Tuebingen
Faculty of Science
Department of Computer Science
Chair of Communication Networks
Sand 13, 72076 Tuebingen, Germany
phone: (+49)-7071/29-70505
fax: (+49)-7071/29-5220
mailto:[email-masked]
http://kn.inf.uni-tuebingen.de

---

From: "Zhulei (A)" <[email-masked]>
Date: Tue, 5 Nov 2013 07:49:16 +0000

Hi all,

This document reminds of thinking of lower layer congestion and queuing mechanisms in network, sometimes which would leverage large coverage. The modes to guide seem all validated and even helpful for my scenarios of some IP-in-IP case as what is saying in draft. So, I would be good for adoption of this draft as a work item, and, would like to promote in this direction by something feedback to WG.

My always thought that the encoding of ECN marking, as in some case the ingress of a tunnel may need the space(s) for following layer3 entities to fill the ECT and location information (at lease e.g. IP address). Obviously, information of location would be only helpful to network operator, but the end point handling ECN marking. 

Best regards,
Zhu Lei
Mobile: +86-13910157020

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Bob Briscoe
发送时间: 2013年11月5日 6:04
收件人: tsvwg IETF list; AQM IETF list
抄送: Pat Thaler; John Kaippallimalil; [email-masked]
主题: [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols?

Folks,

Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP <http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines>

Abstract

Bob Briscoe,

---

From: Piers O'Hanlon <[email-masked]>
Date: Tue, 5 Nov 2013 09:42:31 +0000

Hi Bob,

I took a brief look at the draft and it's clearly useful work.

One thing that could do with clarification in the Introduction is that ECN - by itself - doesn't necessarily lead to low loss and delay - it should be made clear that it reflects the marking approach of the underlying scheme/AQM.

Piers

---

From: Dirk Kutscher <[email-masked]>
Date: Tue, 5 Nov 2013 09:49:34 +0000

Hi,

As earlier indicated, I'd like to see this document being adopted as a tsvwg work item.

I'd be happy to help with reviewing.

Best regards,
Dirk

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Piers O'Hanlon
> Sent: Dienstag, 5. November 2013 10:43
> To: Bob Briscoe
> Subject: Re: [tsvwg] Who supports tsvwg adoption of adding ECN to L2 or
> tunnel protocols?
> 
> Hi Bob,
> 
> One thing that could do with clarification in the Introduction is that ECN - by
> itself - doesn't necessarily lead to low loss and delay - it should be made clear
> that it reflects the marking approach of the underlying scheme/AQM.
> 
> Piers
> 
> IETF transport services w-g (tsvwg). The WG chairs need visibility of interest.

---

From: <[email-masked]>
Date: Tue, 5 Nov 2013 18:32:22 +0000

agree with these comments
best wishes
phil

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Scheffenegger, Richard [[email-masked]]
Sent: 05 November 2013 00:48
To: Matt Mathis; Briscoe,RJ,Bob,TUB8 R
Cc: [email-masked]; tsvwg IETF list; AQM IETF list
Subject: Re: [tsvwg] [aqm] Who supports tsvwg adoption of adding ECN to L2 or tunnel protocols?

(aqm chair hat off)

Richard Scheffenegger

Thanks,
--MM--

Abstract

Bob Briscoe,

---

From: Joe Touch <[email-masked]>
Date: Tue, 05 Nov 2013 10:40:07 -0800

IMO, these guidelines ought to come out in a single recommendation for 
tunnels; we had a draft of that in INTAREA but insufficient momentum.

Piecemeal recommendations are likely to be ignored/lost.

Joe

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 5 Nov 2013 18:41:30 +0000

Piers,

I tried to state exactly how ECN can benefit (2nd para of intro 
below), rather than make overblown claims. You seem to be saying I 
didn't succeed? I can't see how to do any better. Suggestions?

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
ECN removes nearly all congestion loss and it cuts delays for two 
main reasons: i) it avoids the delay when recovering from congestion 
losses, which particularly benefits small flows, making their 
completion time predictably short [RFC2884] and ii) as ECN is used 
more widely by end-systems, it will gradually remove the need to 
configure a degree of delay into buffers before they start to notify 
congestion (the cause of bufferbloat). The latter delay is because 
drop involves a trade-off between sending a timely signal and trying 
to avoid impairment, whereas ECN is solely a signal not an 
impairment, so there is no harm triggering it earlier.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\

PS. Thx for supporting words.

Bob

At 09:42 05/11/2013, Piers O'Hanlon wrote:
>One thing that could do with clarification in the Introduction is 
>that ECN - by itself - doesn't necessarily lead to low loss and 
>delay - it should be made clear that it reflects the marking 
>approach of the underlying scheme/AQM.
>
>Piers
>

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 5 Nov 2013 18:59:18 +0000

Joe,

I envisage that a very brief standards track doc that explicitly 
UPDATES the relevant IETF tunnel specs will be written, and it will 
refer to this doc for rationale.

See Appendix A (outstanding items), which I have also highlighted 
when presenting each time:

    2.  Consider whether an IETF Standard Track doc will be needed to
        Update the IP-in-IP protocols listed in Section 4.1--at least
        those that the IETF controls--and which Area it should sit under.

Does that address your concern?

Bob

At 18:40 05/11/2013, Joe Touch wrote:
>IMO, these guidelines ought to come out in a single recommendation 
>for tunnels; we had a draft of that in INTAREA but insufficient momentum.
>

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 5 Nov 2013 19:22:15 +0000

I do support this work going forward. I do understand Joe's position/desire and while it would be preferable to have a comprehensive document,  I think draft-briscoe is useful by itself. FYI, Joe's draft can be found here

http://tools.ietf.org/html/draft-ietf-intarea-tunnels-00

Thanks
Suresh
 
> Of Bob Briscoe
> Sent: November-05-13 1:59 PM
> To: Joe Touch
> Cc: [email-masked]; tsvwg IETF list
> I envisage that a very brief standards track doc that explicitly UPDATES the
> relevant IETF tunnel specs will be written, and it will refer to this doc for
> rationale.
> 
> See Appendix A (outstanding items), which I have also highlighted when
> presenting each time:
> 
> >>> <http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines
> >>> >
> >>>
> >>>     Abstract
> >>>

---

From: Joe Touch <[email-masked]>
Date: Tue, 05 Nov 2013 12:50:11 -0800

On 11/5/2013 10:59 AM, Bob Briscoe wrote:
> Joe,
>
> I envisage that a very brief standards track doc that explicitly UPDATES
> the relevant IETF tunnel specs will be written, and it will refer to
> this doc for rationale.

Tunnels need to handle ingress/egress translation of all signals in the 
header. This is no different.

My concern is that putting these recommendations in separate places 
gives an opportunity for different groups to have different 
interpretations of that sort of translation, and that's a bad thing IMO.

Joe

---

From: Andrew Mcgregor <[email-masked]>
Date: Wed, 6 Nov 2013 09:59:51 +1100

That's about what I thought the answer would be... but it's worth having
that in the record :-)

On 5 November 2013 11:00, Bob Briscoe <[email-masked]> wrote:

> This is about the interface between lower layers and the ECN field in the
> IP header. We can't really talk about new semantics in lower layers that
> aren't even defined in ECN at the IP layer.
>
> Naively, one could imagine some text treating the ECN field as 4 opaque
> codepoints, and propagating  a similar 4 opaque codepoints from each lower
> layer protocol. Then if something new were defined in IP-ECN like a
> non-congestive loss codepoint, it could also be defined in lower layers...
>
> But that's naive, because each lower layer has it's own constraints and
> ways of handling concepts like "ECN-capable transport", none of which
> easily translates to a simple mapping of codepoints.
>
> * Clearly a link cannot signal that a loss was not due to congestion using
> the lost frame itself (there aren't any bits :)
>   - That frame may go to another process that didn't see any loss; then
> what does the process do?
>   - or the link has to use DPI to signal only in frames going to the same
> process as the lost frame.
> * At my last count, there were at least nine different reasons for packet
> loss. If we had 4 bits spare in each lost packet... :)
>
>
>
> Bob
>
>
>
>  < http://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-encap-guidelines >
>
> Abstract
>

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 6 Nov 2013 22:50:14 +0000

Joe,

The approach of a BCP just about ECN doesn't preclude any of the 
following options for stds track docs:
a) one RFC updating all tunnel specs about ECN
b) one RFC updating all tunnel specs about ECN and Diffserv (the two 
fields that propagate up as well as down).
c) one RFC updating all tunnel specs about everything
d) one RFC per each tunnel spec to wrap up all updates around at the time

These choices are for the relevant ADs and WGs to make.
Writing a BCP in TSV gives the raw info that any of these approaches can use.

Bob

At 20:50 05/11/2013, Joe Touch wrote:

>Tunnels need to handle ingress/egress translation of all signals in 
>the header. This is no different.
>

---

From: Joe Touch <[email-masked]>
Date: Wed, 06 Nov 2013 15:01:42 -0800

Hi, Bob,

IMO, the desciption of how IP header info (which is what I presume 
you're suggesting) to impact L2s (which include tunnels) belongs in a 
tunnel doc, which AFAICT belongs in INTAREA. The tunnel landscape is 
already quite complex.

I have no idea why TSV would be involved in this except if you're 
talking about TCP ECH markings, but IMO the relationship of the TCP mark 
to the IP mark might belong in TSV.

However, I do not think TSV should be promoting having signals "jump" 
layers, i.e., from TCP ECN to its impact on tunnels or L2.

Joe

On 11/6/2013 2:50 PM, Bob Briscoe wrote:
>>>>>> item

---

From: [email-masked]
Date: Wed, 6 Nov 2013 23:00:51 -0000

This message flow about ECN belongs in TSVWG - please do NOT cross post to
the AQM list.

If you are interested in the end-to-end usage of ECN or rules for tunnels,
etc then please do join the TSVWG list.

Gorry

---

---

From: [email-masked]
Date: Wed, 6 Nov 2013 23:00:52 -0000

Gorry

---

---

From: Piers O'Hanlon <[email-masked]>
Date: Thu, 7 Nov 2013 13:26:36 +0000

Bob,

I was thinking that it would be good to add the following clarifications:

Given a suitable marking scheme ECN provides for the removal of nearly all congestion loss and it reduces delays for two main reasons: 
  i) It avoids the delay when recovering from congestion losses, which particularly benefits small flows, making their 
      completion time predictably short [RFC2884]
  ii) As ECN is used more widely by end-systems, it will gradually remove the need to configure a degree of delay
      into buffers before they start to notify congestion (the cause of bufferbloat). 
The latter delay is because a drop involves a trade-off between sending a timely signal and trying to avoid impairment, whereas ECN is solely a signal not an impairment, so there is no harm triggering it earlier.

Cheers,

Piers

On 5 Nov 2013, at 18:41, Bob Briscoe wrote:

> Piers,
> 
> I tried to state exactly how ECN can benefit (2nd para of intro below), rather than make overblown claims. You seem to be saying I didn't succeed? I can't see how to do any better. Suggestions?
> 
> ECN removes nearly all congestion loss and it cuts delays for two main reasons: i) it avoids the delay when recovering from congestion losses, which particularly benefits small flows, making their completion time predictably short [RFC2884] and ii) as ECN is used more widely by end-systems, it will gradually remove the need to configure a degree of delay into buffers before they start to notify congestion (the cause of bufferbloat). The latter delay is because drop involves a trade-off between sending a timely signal and trying to avoid impairment, whereas ECN is solely a signal not an impairment, so there is no harm triggering it earlier.

---

From: Bob Briscoe <[email-masked]>
Date: Thu, 7 Nov 2013 18:38:42 +0000

Piers,

OK. Text altered (even tho some of the gains are much less sensitive 
to marking scheme, the point is of course generally true).

Bob

At 13:26 07/11/2013, Piers O'Hanlon wrote:
>Given a suitable marking scheme ECN provides for the removal of 
>nearly all congestion loss and it reduces delays for two main reasons:
>   i) It avoids the delay when recovering from congestion losses, 
> which particularly benefits small flows, making their
>   ii) As ECN is used more widely by end-systems, it will gradually 
> remove the need to configure a degree of delay
>The latter delay is because a drop involves a trade-off between 
>sending a timely signal and trying to avoid impairment, whereas ECN 
>is solely a signal not an impairment, so there is no harm triggering 
>it earlier.
>
>Cheers,
>
>Piers
>
> main reasons: i) it avoids the delay when recovering from 
> congestion losses, which particularly benefits small flows, making 
> their completion time predictably short [RFC2884] and ii) as ECN is 
> used more widely by end-systems, it will gradually remove the need 
> to configure a degree of delay into buffers before they start to 
> notify congestion (the cause of bufferbloat). The latter delay is 
> because drop involves a trade-off between sending a timely signal 
> and trying to avoid impairment, whereas ECN is solely a signal not 
> an impairment, so there is no harm triggering it earlier.
> > 
> >> One thing that could do with clarification in the Introduction 
> is that ECN - by itself - doesn't necessarily lead to low loss and

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Fri, 8 Nov 2013 19:49:05 +0000

At 23:04 04/11/2013, Andrew Mcgregor wrote:
> This seems like valuable work.  One question is, can we put in scope notification that losses are NOT due to congestion?

Speaking for myself, I'm not sure how I would do that.

A loss (or mark) due to congestion is pretty simple. The switch knows what it did. 

To know that a packet was lost for reasons other than congestion, I need to somehow know what packets I should expect, and infer that something that I expected didn't happen. In TCP, we know about data segments because they are enumerated - I know what the next octet sequence number to expect, and it doesn't arrive. Control segments (SYN, ACK, FIN, RST, and so on) are not enumerated in that sense - if my peer sends ten identical acks and nine arrive, I as the receiver have no way to know that. At the link layer, most link protocols in use today (PPP, Ethernet, and so on) do not enumerate packets in flight - they are simply there. I *might* be able to see a burst of noise on the line, but only if it looks like it might be the start of a packet and then doesn't end with the right checksum. Even if I can see it, I have no way to know whether the noise garbled one packet or many.

If you want to do some research and come up with a solution, be my guest. But in a standard discussed in 2013... let's not.

---

From: Andrew Mcgregor <[email-masked]>
Date: Fri, 8 Nov 2013 12:38:21 -0800

I agree, non-congestive loss notification is a research problem.  So, out
of scope for the IETF right now but I hope someone thinks about it (I will,
as a background task).

On 8 November 2013 11:49, Fred Baker (fred) <[email-masked]> wrote:

> To know that a packet was lost for reasons other than congestion, I need
> to somehow know what packets I should expect, and infer that something that
> I expected didn't happen. In TCP, we know about data segments because they
> are enumerated - I know what the next octet sequence number to expect, and
> it doesn't arrive. Control segments (SYN, ACK, FIN, RST, and so on) are not
> enumerated in that sense - if my peer sends ten identical acks and nine
> arrive, I as the receiver have no way to know that. At the link layer, most
> link protocols in use today (PPP, Ethernet, and so on) do not enumerate
> packets in flight - they are simply there. I *might* be able to see a burst
> of noise on the line, but only if it looks like it might be the start of a
> packet and then doesn't end with the right checksum. Even if I can see it,
> I have no way to know whether the noise garbled one packet or many.
>
> If you want to do some research and come up with a solution, be my guest.
> But in a standard discussed in 2013... let's not.
>

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 12 Nov 2013 11:20:57 +0000

Fred,

For the record, Andrew and I spent an evening to see if we could come 
up with a solution to indicate non-congestive loss. We started with a 
list of 9 different causes of loss (from my PhD thesis). We worked 
through a number of ideas, but they all exhibit varying degrees of problems.

So we all agree indicating non-congestive loss is a research problem for now...

Bob

At 20:38 08/11/2013, Andrew Mcgregor wrote:
>I agree, non-congestive loss notification is a research 
>problem.  So, out of scope for the IETF right now but I hope someone 
>thinks about it (I will, as a background task).
>
>
>On 8 November 2013 11:49, Fred Baker (fred) 
><<mailto:[email-masked]>[email-masked]> wrote:
>
> > This seems like valuable work.  One question is, can we put in 
> scope notification that losses are NOT due to congestion?
>
>To know that a packet was lost for reasons other than congestion, I 
>need to somehow know what packets I should expect, and infer that 
>something that I expected didn't happen. In TCP, we know about data 
>segments because they are enumerated - I know what the next octet 
>sequence number to expect, and it doesn't arrive. Control segments 
>(SYN, ACK, FIN, RST, and so on) are not enumerated in that sense - 
>if my peer sends ten identical acks and nine arrive, I as the 
>receiver have no way to know that. At the link layer, most link 
>protocols in use today (PPP, Ethernet, and so on) do not enumerate 
>packets in flight - they are simply there. I *might* be able to see 
>a burst of noise on the line, but only if it looks like it might be 
>the start of a packet and then doesn't end with the right checksum. 
>Even if I can see it, I have no way to know whether the noise 
>garbled one packet or many.
>
>If you want to do some research and come up with a solution, be my 
>guest. But in a standard discussed in 2013... let's not.
>

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 12 Nov 2013 17:20:10 +0000

Thanks. 

Personally, I think it is two problems. One, which I imagine is the one you worked on, is the question of detection; we can detect loss at an endpoint (it doesn't see something it expects to see) but not reliably (it might not be expecting something, but an outside observer expects it to see something, and it doesn't see it). The other is the question of what one does about it. If it is an unreliable interface injecting packet errors, one can route around it. If it's a wireless interface (unreliable in the sense that the probability of error is non-negligible), one might route around it, or one might impose some variation on ARQ or FEC, as we do in WiFi and other technologies. If it's another source of non-congestive loss, I suspect that the solution is somehow tailored to the mode of operation.

I can tell you that we have a capability for video streaming applications in which we enumerate packets and literally send two streams on disjoint paths. At the receiving end, we discard the second instance of a packet that arrives. In the event of loss in the network, we expect that to reduce the probability of non-delivery to a negligible value. Solutions like that can be a cost-effective solution to non-congestive loss, I should think.

On Nov 12, 2013, at 3:20 AM, Bob Briscoe <[email-masked]> wrote:

> Fred,
> 
> For the record, Andrew and I spent an evening to see if we could come up with a solution to indicate non-congestive loss. We started with a list of 9 different causes of loss (from my PhD thesis). We worked through a number of ideas, but they all exhibit varying degrees of problems.
> 
>> I agree, non-congestive loss notification is a research problem.  So, out of scope for the IETF right now but I hope someone thinks about it (I will, as a background task).
>> 
>> 

Make things as simple as possible, but not simpler.
Albert Einstein