Re: [conex] Accounting of ConEx signals

[Mirja Kuehlewind <[e-mail]>]

Hi Richard,

after reading the relevant parts of the RFCs stated below again, I would say 
the answer is more or less obvious.

A sender does not have any feedback information (no ECN nor loss detection) 
about control packets not carrying any user data. Of course those packets can 
cause congestion as well but neither the sender nor the audit will be able to 
detect this congestion. That means a sender can only give conex feedback 
about the all other packets and this conex information must be seen with 
respect to only those packets we have congestion information about.
Suddenly an IP packet with ConEx header but X bit no set makes sense. I added 
this to the most current version of the IP Dest Opt draft.

SYN and SYN/ACK might be a different case for ECN. But for ConEx as this is 
the first packet sent, for sure we do not have any congestion feedback 
information yet and taking the SYN or SYN/ACK into account when calculating 
the congestion level should usually not really make a big difference as you 
need anyway a certain amount of packets before you can get a significant 
result.

Regarding the retransmitted packets, we, kind of, have information about, even 
though they are not ECN-capable, because the RTO might cause a sender to 
retransmit a restransmitted packet again. The reason for ECN to make 
retransmitted as not-ECN-capable is because the receiver might not see a 
unnecessarily-retransmitted packet and thus might not report an CE mark on an 
unnecessarily-retransmitted packet to the sender. In our case the ConEx is 
meant to be information for network nodes and not for the receiver, thus it 
is not a problem. I would recommend to make restransmitted packet 
ConEx-capable.

For the TCP modifications draft, we can simply account the TCP payload, when 
we assume equal sized packets, as the conex marked packet as well as the 
original packets causing the congestion will both have a header of the same 
size. 
In case of not equal sized packets we have to account the headers as well but 
we cannot provide a generic way how to do this. A sender which sends 
different sized packets probably knows about the pattern/reason to do so and 
thus can reconstruct the exact number of headers based on this information.

Any thoughts?
Mirja


On Tuesday 11 October 2011 20:05:25 Scheffenegger, Richard wrote:
> Bob, Mirja,
>
> Currently, there are probably two relevant RFCs in this space - RFC5562
> (experimental) and RFC5590 (informational), which Bob already mentioned.
>
> RFC5562 adds one specific case of control packets [SYN,ACK] to the
> ECT-capable packets.
>
> So there exists at least one case, where a pure control packet in TCP may
> carry ECN information. RFC5562 is actually implemented and available in IBM
> AIX5.3 and later.
>
>
> I believe it should be clear that Conex Marks should only be carried on
> those packets, that the transport layer would mark ECN-capable.
>
> Further, Section 6.1.5 in RFC3168 also states, that retransmitted packets
> should not be sent with ECT. That probably settles the discussion, if a
> Conex L mark should be sent right with the retransmission of the loss. If
> I'm not mistaken that Conex "requires" a ECN capable transport (and
> therefore a qualifying transport segment).
>
> However, there are some obvious potential issue with such an approach; for
> example, a CE-marked SYN-ACK may never be followed by a data segement which
> could carry the Conex E mark for an extensive period of time. Same could
> hold for a retransmission which may be the last data to be sent to the
> receiver, again for some (human scale) time periods - as tcp keepalive /
> window probe windows by definition won't carry ECT / Conex, correct?
>
>
> Alternatively, Conex marks can be completely decoupled from the transport
> (or rather, sent with every packet of that ECN-capable transport,
> regardless if the transport actually sends a ECT packet or not). That would
> alleviate some of the potential implication a long delayed conex signal may
> cause...
>
> (Note: reECN implicitly coupled re-ECN marks with ECT, always; but with the
> current IPv6 signaling scheme, this is no longer absolutely required).
>
> Best regards,
>
>
> Richard Scheffenegger
>
> > -----Original Message-----
> > From: Bob Briscoe [mailto:[e-mail]]
> > Sent: Dienstag, 11. Oktober 2011 14:35
> > To: Mirja Kuehlewind
> > Cc: [e-mail]; Scheffenegger, Richard
> > Subject: Re: [conex] Accounting of ConEx signals
> >
> > Mirja,
> >
> > If pure acks were ECN-capable, it would be just
> > as likely that they would get an ECN mark as any
> > data packet. However, RFC3168 says pure ACKS must
> > be sent as Not-ECT. We should keep to this in
> > ConEx unless something better has been done that
> > I'm not aware of - ConEx isn't chartered to work on loss/marking of
> > pure acks.
> >
> > There is RFC5690, which is informational (rather than experimental):
> > "Adding Acknowledgement Congestion Control to TCP"
> >
> > The relevant section in the re-ECN spec about
> > pure acks, and byte vs packet ConEx signalling is
> > here, which covers nearly everything in the present thread:
> > <http://tools.ietf.org/html/draft-briscoe-tsvwg-re-ecn-tcp-09#section-
> > 6.1.5>
> >
> >
> > This leaves the outstanding question of which
> > ConEx doc should write about this stuff.
> > * abstract-mech ought to cover things like which packet headers to
> > include.
> > * conex-tcp-modifications obviously ought to talk about TCP-specifics
> > * that leaves where to put design principles
> > applicable to all transports. 2 options:
> >    a) abstract-mech?
> >    b) a section in conex-tcp-modifications 'guidelines for other
> > transports'?
> >
> > I prefer a) but we don't really want extremely detailed stuff in
> > abstract-mech.
> >
> >
> > Bob
> >
> > At 12:42 11/10/2011, Mirja Kuehlewind wrote:
> > >Hi Bob,
> > >
> > >thanks for this separate answer on the second
> > >question but actually your first
> > >answer help me already. When I was reading your mail, I've just
> >
> > though, that
> >
> > >we can at the endsystem just count the TCP payload. Under the
> >
> > assumption that
> >
> > >the endsystem is mostly sending equally sized packets, there will be
> > >automatically as many header with ConEx marks as there have been
> >
> > causing the
> >
> > >original congestion. If the sender is doing some wired things, like
> >
> > sending
> >
> > >smaller retransmit packets, the sender knows about it and can take
> >
> > exactly
> >
> > >this knowledge into account.
> > >
> > >I talked to Richard about this and he was bring
> > >up the case, when there is ACK
> > >congestion (control packets without payload get marked). Not sure what
> >
> > to do
> >
> > >with this case. If an ACK get lost, we actually don't really know. We
> >
> > could
> >
> > >assume that the receiver should ack as least every second packet but
> >
> > we never
> >
> > >know what the receiver did. I believe usually control packets without
> >
> > payload
> >
> > >are as well ECN-capable. So with ECN we  would have a congestion
> >
> > signal. But
> >
> > >is this a common case that pure ACKs get ECN markings?
> > >
> > >Mirja
> > >
> > >On Monday 10 October 2011 18:46:06 Bob Briscoe wrote:
> > > > Mirja,
> > > >
> > > > The thread largely overlooked your second question, which is also a
> >
> > good
> >
> > > > one.
> > > >
> > > > We haven't got any text anywhere that talks about this.
> > > >
> > > > IMO the size should include the network layer header, but not link
> >
> > layer.
> >
> > > > Reason: ConEx is targeted at the IP layer because
> > > > it is the interoperability layer across networks.
> > > > When the bytes of a packet cause congestion
> > > > (setting aside the discussion about packet
> > > > processing congestion), the IP header is always
> > > > there, so it is part of the size that always needs to be counted.
> > > >
> > > > So, when we add ConEx to TCP, byte-for-byte
> > > > balance should strictly take account of IP
> > > > headers. But as you rightly point out, TCP often
> > > > doesn't know how many IP headers are involved (or
> > > > how many TCP headers were involved the last time
> > > > round the loop). So again, we can only say that
> > > > the practical approach when coding TCP is to make
> > > > assumptions about IP and TCP headers (e.g. assume
> > > > there will always be about the same amount of IP
> > > > and TCP header size added to the same amount of TCP payload).
> > > >
> > > > This should be good enough at this experimental
> > > > stage. If it raises problems, we will have to deal with them.
> > > >
> > > >
> > > > Bob
> > > >
> > > > PS. Strictly, congestion at the link layer
> > > > includes the size of link layer headers, and
> > > > congestion in a tunnel includes tunnel headers,
> > > > etc, etc. But for simplicity, from the
> > > > transport's viewpoint, I think it's reasonable to
> > > > use the size of the packet including the one IP
> > > > header that the transport can assume. This is a
> > > > bit like the transport layer checksum calculation
> > > > that includes an IP pseudo-header. But in this
> > > > case, the transport just adds a pseudo-size for the IP and TCP
> >
> > headers.
> >
> > > > At 00:15 07/10/2011, Mirja Kühlewind wrote:
> > > > >2. Which bytes of a packet do we take? The IP length incl header,
> >
> > the IP
> >
> > > > >payload incl. TCP header or the actual payload?
> > > > >In TCP if a packet get lost (with SACK) we only know how many
> >
> > payload got
> >
> > > > >lost. We do not know the number of packets/headers that were used
> >
> > to
> >
> > > > > transmit this data. If we would loose one big packet and then
> >
> > retransmit
> >
> > > > > a large number of small packets instead (which are all ConEx
> >
> > marked) that
> >
> > > > > might give quite a different ConEx signal. On the other hand,
> >
> > what causes
> >
> > > > > the congestion is the whole packet incl header(s). What is the
> >
> > right
> >
> > > > > thing to do?
> > > >
> > > > ________________________________________________________________
> > > > Bob Briscoe,                                BT Innovate & Design
> > >
> > >--
> > >-------------------------------------------------------------------
> > >Dipl.-Ing. Mirja Kühlewind
> > >Institute of Communication Networks and Computer Engineering (IKR)
> > >University of Stuttgart, Germany
> > >Pfaffenwaldring 47, D-70569 Stuttgart
> > >
> > >tel: [phone]
> > >email: [e-mail]
> > >web: www.ikr.uni-stuttgart.de
> > >-------------------------------------------------------------------
> >
> > ________________________________________________________________
> > Bob Briscoe,                                BT Innovate & Design



-- 
-------------------------------------------------------------------
Dipl.-Ing. Mirja Kühlewind
Institute of Communication Networks and Computer Engineering (IKR)
University of Stuttgart, Germany
Pfaffenwaldring 47, D-70569 Stuttgart

tel: [phone]
email: [e-mail]
web: www.ikr.uni-stuttgart.de
-------------------------------------------------------------------