Subject: [tcpm] draft-ietf-tcpm-accecn-reqs-03

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

Hi all,

Quickly scanning through draft-ietf-tcpm-accecn-reqs-03... 

The main diff in -03 is:

     "Overhead	
			A more accurate ecn feedback signal should limit the	
			additional network load. As feedback information has to be	
			provided timely and frequently, potentially all or a large	
			fraction of TCP acknowledgments will carry this information.	
			Ideally, no additional segments are exchanged compared to a	
			standard RFC3168 TCP session, while the overhead in each	
			segment is kept minimal. Further, a feedback mechanism	
			should be prepared to proved a method to fall-back to well	
			known RFC3168 signaling, if the new signal is suppressed by	
			middleboxes."

For what it is worth, I don't think that the sentence is about overhead. It probably justifies a separate category such as "middlebox-compliance" (maybe somebody has a better work for broken devices between the TCP endpoints?).

As a side node, I wonder if it has been discussed somewhere if the SACK option could be used for accurate ECN feedback. E.g., something like SACK blocks below the cumulative ACK (or combined with some other signaling). I don't claim this to be a good idea, but I don't recall a discussion on that out of my head. Do I miss something obvious?

Thanks

Michael

---

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 29 Jul 2013 10:28:28 +0000

Hi Michael,

the obvious objection to

> SACK blocks below the cumulative ACK

Is D-SACK, which does something similar; however, D-SACK only specifies the signaling, not the mechanism. Re-using that has the potential to confuse senders (a receiver indicating two segments arrived, which weren't sent by the sender; similar to network segment duplication), and overloading this with an additional signal has the potential to make clear distinctions more hard (network duplication, spurious retransmission and ECN signal).

Best regards,

Richard Scheffenegger

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Scharf, Michael (Michael)
> Sent: Montag, 29. Juli 2013 11:21
> To: [email-masked] Extensions
> Subject: [tcpm] draft-ietf-tcpm-accecn-reqs-03
> 
> Hi all,
> 
> For what it is worth, I don't think that the sentence is about overhead.
> It probably justifies a separate category such as "middlebox-compliance"
> (maybe somebody has a better work for broken devices between the TCP
> endpoints?).
> 
> As a side node, I wonder if it has been discussed somewhere if the SACK
> option could be used for accurate ECN feedback. E.g., something like SACK
> blocks below the cumulative ACK (or combined with some other signaling). I
> don't claim this to be a good idea, but I don't recall a discussion on
> that out of my head. Do I miss something obvious?
> 
> Thanks
> 
> Michael
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

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

> Is D-SACK, which does something similar; however, D-SACK only 
> specifies the signaling, not the mechanism. Re-using that has 
> the potential to confuse senders (a receiver indicating two 
> segments arrived, which weren't sent by the sender; similar 
> to network segment duplication), and overloading this with an 
> additional signal has the potential to make clear 
> distinctions more hard (network duplication, spurious 
> retransmission and ECN signal).

Well, obviously I do not suggest *only* using SACK blocks. I was thinking of something like

- an "ECN-SACK block" (semantics: "This byte range got ECN marked.")

or

- a flag in the TCP header that makes it clear how the receiver generated the D-SACK based on ECN marking.

The point is that instead of returning counters (cf. draft-kuehlewind-tcpm-accurate-ecn-option), one could return byte ranges. This has obvious disadvantages (option space consumption etc.), but since this document briefly surveys the solution space, I wonder whether you could comment on non-counter-based feedback schemes.

Michael (naive TCP researcher)

> > From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> > Of Scharf, Michael (Michael)
> > As a side node, I wonder if it has been discussed somewhere if the 
> > SACK option could be used for accurate ECN feedback. E.g., 
> something 
> > like SACK blocks below the cumulative ACK (or combined with 
> some other 
> > signaling). I don't claim this to be a good idea, but I 
> don't recall a 
> > discussion on that out of my head. Do I miss something obvious?
> > 
> > Thanks
> > 
> > Michael